sr-users September 2010

sr-users@lists.kamailio.org

58 participants
97 discussions

is db accounting non-blocking?
by Klaus Darilion 08 Sep '10

08 Sep '10

Hi! Is DB accounting (mysql) asynchronous? I.e. if non-local DB is slow - does this affect Kamailio's message routing? thanks Klaus

2 1

TM question
by Alex Balashov 08 Sep '10

08 Sep '10

Hi, I have a somewhat unusual log entry after some calls: Sep 3 09:12:23 kamgw01 /usr/local/sbin/kamailio[542]: WARNING: tm [t_lookup.c:1551]: WARNING: script writer didn't release transaction These calls fail in that they are processed instantly, but no time is ever given to receive a response from the upstream gateway. For instance, the above call's initial INVITE was received at 09:12:23, a final request URI was resolved, and then this message, all in < 1 second. Trace on upstream gateway shows that the initial request was never received from Kamailio. There is one additional aspect to how these calls are being processed in script that almost certainly has a bearing on this, though I don't know what it is: They are handled through a gateway route route called route[OUTBOUND-ROUTE-TRY] that is, under normal circumstances reflecting its name, initially called from the request route, and subsequently from a failure route meant to advance it. Normal operation mode is like this: route { ... route(OUTBOUND-ROUTE-TRY); } route[OUTBOUND-ROUTE-TRY] { if(dialog_count_of_vendor_gw < limit) { t_on_failure("OUTBOUND-ROUTE-FAILURE"); if(!t_relay()) { sl_reply_error(); } exit; } else { ... # Advance index of AVP array to next gateway, etc. # if(!t_lookup_request()) t_newtran(); route(OUTBOUND-ROUTE-TRY); exit; } } ... # Armed in OUTBOUND-ROUTE-TRY with t_on_failure(). failure_route[OUTBOUND-ROUTE-FAILURE] { ... # If we have more routes to retry, call # OUTBOUND-ROUTE-TRY again. route(OUTBOUND-ROUTE-TRY); } However, what is happening to cause this error is a little different from the usual scenario. On the initial attempt, the dialog limit check you see in OUTBOUND-ROUTE-TRY is failing, so the route adds a new transaction and calls itself again once. Now, the reason I am creating a new transaction is because in certain failure modes when a transaction was never created (like, if the call also fails on the next attempt), it is otherwise not possible to send a stateful failure reply to the originating endpoint from the failure route, which is a requirement (one cannot issue stateless replies from failure routes). So, because this routine is called both from the failure route and from the request route, I create a new transaction in order to make it possible to send stateful replies (t_reply()) from within this route regardless of the type of the parent route calling it, whether it is failure route or request route. So, again, what is happening in the scenario in which I get the above log message is: 1. INVITE is received 2. Master request route runs OUTBOUND-ROUTE-TRY request route 3. OUTBOUND-ROUTE-TRY checks gateway limit, finds it is exceeded 4. OUTBOUND-ROUTE-TRY checks request against existing transaction, and if not found, creates a new one with t_newtran() 5. OUTBOUND-ROUTE-TRY calls itself again. 6. OUTBOUND-ROUTE-TRY succeeds this time, but evidently, t_relay() fails with the above message, or above message appears sometime before t_relay() is called. Any insight is appreciated! Thanks, -- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/

2 5

offset exceeds message size crash
by federico cabiddu 08 Sep '10

08 Sep '10

Hi, I'm using kamailio 1.5.4-notls and I'm experimenting crashes when an UAC sends an INVITE with a content-length greater then the effective body length. The error messages written on the logs is: CRITICAL:core:del_lump: offset exceeds message size (1266 > 1161) aborting... and this is the backtrace of the generated core file: #0 0x00002ad718ab307b in raise () from /lib/libc.so.6 (gdb) bt #0 0x00002ad718ab307b in raise () from /lib/libc.so.6 #1 0x00002ad718ab484e in abort () from /lib/libc.so.6 #2 0x0000000000418f53 in del_lump (msg=0x66de00, offset=1266, len=12, type=HDR_OTHER_T) at data_lump.c:292 #3 0x00002ad71a8145ba in alter_mediaip (msg=0x66de00, body=<value optimized out>, oldip=0x7fff81fe6700, oldpf=<value optimized out>, newip=0x7fff81fe66e0, newpf=2, preserve=0) at nathelper.c:1857 #4 0x00002ad71a821a3a in force_rtp_proxy (msg=0x66de00, str1=<value optimized out>, str2=<value optimized out>, offer=<value optimized out>) at nathelper.c:2871 #5 0x00002ad71a8238df in rtpproxy_offer1_f (msg=0x66de00, str1=0x65f370 "cof", str2=<value optimized out>) at nathelper.c:2391 #6 0x000000000040cc5a in do_action (a=0x65f400, msg=0x66de00) at action.c:874 #7 0x000000000040f19f in run_action_list (a=<value optimized out>, msg=0x66de00) at action.c:145 #8 0x0000000000454155 in eval_expr (e=0x65f4d0, msg=0x66de00, val=0x0) at route.c:1171 #9 0x0000000000453bd7 in eval_expr (e=0x65f518, msg=0x66de00, val=0x0) at route.c:1488 #10 0x0000000000453b7f in eval_expr (e=0x65f560, msg=0x66de00, val=0x0) at route.c:1493 #11 0x000000000040c4c9 in do_action (a=0x65ffe8, msg=0x66de00) at action.c:729 #12 0x000000000040f19f in run_action_list (a=<value optimized out>, msg=0x66de00) at action.c:145 #13 0x000000000040dbc9 in do_action (a=0x660528, msg=0x66de00) at action.c:746 #14 0x000000000040f19f in run_action_list (a=<value optimized out>, msg=0x66de00) at action.c:145 #15 0x000000000040dbc9 in do_action (a=0x6606c8, msg=0x66de00) at action.c:746 #16 0x000000000040f19f in run_action_list (a=<value optimized out>, msg=0x66de00) at action.c:145 #17 0x000000000040dac5 in do_action (a=0x656790, msg=0x66de00) at action.c:120 #18 0x000000000040f19f in run_action_list (a=<value optimized out>, msg=0x66de00) at action.c:145 #19 0x000000000040dbc9 in do_action (a=0x656860, msg=0x66de00) at action.c:746 #20 0x000000000040f19f in run_action_list (a=<value optimized out>, msg=0x66de00) at action.c:145 #21 0x000000000040dac5 in do_action (a=0x6560b0, msg=0x66de00) at action.c:120 #22 0x000000000040f19f in run_action_list (a=<value optimized out>, msg=0x66de00) at action.c:145 #23 0x000000000040f4f3 in run_top_route (a=0x64b870, msg=0x66de00) at action.c:120 #24 0x0000000000444e90 in receive_msg ( buf=0x619a20 "INVITE sip:xxxxxxxx@xxxxxxxxxxxx SIP/2.0\r\nVia: SIP/2.0/UDP xxx.xxx.xxx.xxx:xxxx;branch=z9hG4bK-d8754z-24245342621eb55b-1---d8754z-;rport\r\nMax-Forwards: 69\r\nContact: <sip:xxxxxxxx@xxx.xxx.xxx.xxx"..., len=1161, rcv_info=0x7fff81fe86e0) at receive.c:175 #25 0x0000000000479254 in udp_rcv_loop () at udp_server.c:449 #26 0x0000000000427237 in main (argc=7, argv=0x7fff81fe88e8) at main.c:774 I couldn't get to reproduce this behavior in my test development (it has newer version of glibc) in which I only get the messages: ERROR:core:anchor_lump: offset exceeds message size (1125 > 714)... ERROR:nathelper:force_rtp_proxy: anchor_lump failed Looking into nathelper code, extract_body function I found that the body->len value is taken from Content-Length header, so i added the following piece of code: --- nhelpr_funcs.c.orig 2010-09-02 14:04:09.891649254 +0200 +++ nhelpr_funcs.c 2010-09-02 14:17:40.183747107 +0200 @@ -196,6 +196,12 @@ LM_ERR("message body has length zero\n"); goto error; } + + if (body->len + body->s > msg->buf + msg->len) { + LM_ERR("content-length exceeds packet-length by %d\n", + (body->len + body->s) - (msg->buf + msg->len)); + body->len=strlen(body->s); + } /* no need for parse_headers(msg, EOH), get_body will * parse everything */ This way if the Content-Length header is greater then the effective body length body->len is corrected with the real value. This solved for the moment, but I'm not sure if this is a good approach and I still don't understand why in the test platform I cannot reproduce the crash. Regards, Federico Cabiddu

2 2

route_graph tool
by Daniel-Constantin Mierla 07 Sep '10

07 Sep '10

1 0

time format in db_flatstore
by SIP Projects 07 Sep '10

07 Sep '10

Using version 1.5.2. Trying to migrate acc from db_mysql to db_flatstore to reduce io wait during heavy dialing. However, the default time format changes from normal YYYY-MM-DD hh:mm:ss to unixtime in flatstore. I tried using $TF but its format is even more non-standard. Is there a way to change time format for either the default acc time field in the db_flatstore module or $TF? Thanks, Matt

2 1

some issues in Kamailio WITH FreeSWITCH, SOS
by Abhishek [ABK] Kumar 07 Sep '10

07 Sep '10

Hi SiP-Users, I got kamailio installed and configured to work using mysql with FreeSWiTCH using this HowTo wiki freeswitch:kamailio-3.0.x-freeswitch-1.0.6d-ms [Asipto - SIP and VoIP Knowledge Base Site]<http://kb.asipto.com/freeswitch:kamailio-3.0.x-freeswitch-1.0.6d-ms>: http://kb.asipto.com/freeswitch:kamailio-3.0.x-freeswitch-1.0.6d-ms This is also reference on FreeSWITCH portal and was the only decent tutorial I was able to find on integrating Kamailio with FreeSWITCH. Followed everything successfully, but I have a slight confusion/problem in its wonderful working... >From all tests I performed, I perceived following activities: a.) it handled the extensions added to it very well, and carried over the call to destination extension b.) if destination extension is also added to it, call established without intervention of FreeSWITCH c.) if extension is not added to it but FreeSWITCH, the call reached FreeSWITCH but was rejected there d.) Red5Phone (developed over RED5 Server, @Google-Code) could dial with success but didn't received any Now, *for point (a)* Thank You! *for point (b)* it should be transferred to FreeSWITCH and that should be allowed to establish call, otherwise all dial-plans,etc. goes waste *for point (c)* may be some settings in Wiki are Obsolete OR New, could you please point it out *for point (d)* it may be due to point (b) -- -- Regards, Abhishek Kumar https://sites.google.com/site/abhikumar163/ -- --------------ABK-----mail.signature-------------------- <http://www.blogger.com/profile/06276198262605731980><http://abhishekkr.deviantart.com/><http://www.facebook.com/aBionic><http://www.twitter.com/aBionic><http://sourceforge.net/users/abhishekkr><http://www.youtube.com/user/1ABK><http://in.linkedin.com/in/abionic> ----------------------------------------------------------- ~=ABK=~

2 1

kamailio and asterisk proiblem
by chuks＠cybernergies.com 07 Sep '10

07 Sep '10

2 1

[patch] make install fails with a bash syntax error
by Dmitry Goncharov 07 Sep '10

07 Sep '10

Please, have a look http://sip-router.org/tracker/index.php?do=details&task_id=87. Regards, Dmitry

2 1

High performance routing options
by anthony thomas 07 Sep '10

07 Sep '10

Hi everyone, We are looking at offloading routing logic out of our existing softswitch using openser as an external redirect server. Our routing logic is not terribly complicated and I think both carrierroute and LCR modules would be able to handle it but we have a pretty large route list table with around 30 million records (our routing table is 300k codes but keep different tables per client), 25-30 calls per sec would be enough. >From a performance point of view, what would be the best bet within both modules? also, are both modules actively maintained? Thanks, Anthony

6 13

Routing issues with SIP Route headers.
by Siddhardha Garige 07 Sep '10

07 Sep '10

Hello all, I am having little trouble routing registrations based on route header in following configuration. UA sends registration to P1 and P1 is ignoring “route header” and forwards registration request to Registrar. I am using default kamailio configuration. Is there any thing I need to add to default config to enable route headers? UA----------------->proxy1(kamailio)------------------->proxy2------------------>Registrar REGISTER sip:Registrar.com SIP/2.0 Via: SIP/2.0/UDP 10.18.0.67:5060;branch=z9hG4bKd209323e;rport Route: <sip:proxy2.com;lr> Max-Forwards: 70 From: <sip:xxxxxx@registrar.com>;tag=a85f9424 To: <sip:xxxxx@registrar.com> Contact: <sip:xxxxxxx@10.18.0.67> Call-ID: 431368ae25a3e232 CSeq: 100 REGISTER Expires: 840 Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,UPDATE,SUBSCRIBE,NOTIFY Supported: User-Agent: xg-tx60 3.1.17 (VeriCall Edge) Content-Length: 0 ThanksSid "May the light be with you." ______________________________________________ Siddhardha Garige www.luminepixels.com

3 4

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

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 September 2010