February 2011 - sr-users

Kamailio 3.0.4: Segfault at 4 [..] error 4 in dialog.so
by Klaus Feichtinger 17 Feb '11

17 Feb '11

Hello, does anybody have an idea, what this error messages could mean? Feb 16 11:23:27 SipSrvLstI1 kernel: [429767.707165] kamailio[10758]: segfault at 4 ip b78ba6e5 sp bfacece0 error 4 in dialog.so[b78a0000+32000] Feb 16 13:40:42 SipSrvLstI1 kernel: [438003.071797] kamailio[24880]: segfault at 4 ip b79416e5 sp bff7d460 error 4 in dialog.so[b7927000+32000] Feb 16 18:47:25 SipSrvLstI1 kernel: [456406.166885] kamailio[20939]: segfault at 4 ip b78d56e5 sp bfd821c0 error 4 in dialog.so[b78bb000+32000] I am setting the dialog flag for any incoming call..... Whenever a load test is running, this error occurs. I am not sure if it is reproduceable, or not. But I think it should be, because in worst case (during a load test over night) this error was indicated in a period of 1-2 minutes. But I've found this error only yesterday, because the server was down (as a result of this error....). The daemon (kamailio_3.0.4+lenny1_i386.deb) is running on a virtual machine (ESX) with OS Debian Lenny. How can I find / deliver additional info to this error / fault for analyzation? Thanks for any hints. Klaus

2 1

ACC og ACC_RADIUS module
by Morten Isaksen 17 Feb '11

17 Feb '11

Hi, We have a OpenSER 1.1 platform running with radius accounting and I am in the progress of updating it to Kamailio 3.1. I am trying to decide if I should do accounting via Radius or directly to MySQL on the new platform. The only benefits a can see with Radius is that you can build some redundancy into your radius client. If one Radius server is failing then try the next and you can configure radius to log to a file if the DB is down. But i think you can get the same level of redundancy with a replicated DB setup with heartbeat/pacemaker. If I choose to do the accounting direct to MySQL I will skip the Radius layer (and one error source). Are there any other pros and cons? -- Morten Isaksen

2 1

ERROR: failover functions used, but AVPs paraamters required are NULL
by Gary Chen 17 Feb '11

17 Feb '11

kamailio version 3.1.2 I am trying to setup dispatcher to use its failover feature. Here is dispatcher part of configure file: loadmodule "dispatcher.so" modparam("dispatcher", "db_url", DBURL) modparam("dispatcher", "table_name", "dispatcher") modparam("dispatcher", "ds_ping_interval", 30) modparam("dispatcher", "ds_probing_threshhold", 10) modparam("dispatcher", "ds_ping_reply_codes", "class=2;class=4") modparam("dispatcher", "ds_probing_mode", 1) modparam("dispatcher", "ds_ping_from", "sip:lb1 <at> m-lab-ca805-sig.kd-lab.de") modparam("dispatcher", "dst_avp", "$avp(dsdst)") modparam("dispatcher", "grp_avp", "$avp(dsgrp)") modparam("dispatcher", "cnt_avp", "$avp(dscnt)") modparam("dispatcher", "attrs_avp", "$avp(dsattrs)") modparam("dispatcher", "dstid_avp", "$avp(dsdstid)") modparam("dispatcher", "flags", 2) But it is still give the following error: 0(1917) ERROR: dispatcher [dispatcher.c:624]: failover functions used, but AVPs paraamters required are NULL -- feature disabled Does anybody know why? Gary

2 1

Re: [SR-Users] pdb module timeouts
by Thomas Baumann 16 Feb '11

16 Feb '11

2 1

Re: [SR-Users] Kamailio 1.5.4 and beyond - mhomed issue under Linux
by Sean O'Donnell 16 Feb '11

16 Feb '11

Hi Marius, Thanks for the reply. I found the patch in the 1.5 CVS branch. By the way, the 1.5.5 source tarball in /pub/kamailio/1.5.5/src was created before this patch was written, so the patch is not in there. The tarball I created from the 1.5 branch did have it. Thanks again, Sean O'Donnell Senior Engineer uReach Technologies, Inc. ---- On Mon, 14 Feb 2011, marius zbihlei (marius.zbihlei(a)1and1.ro) wrote: On 02/11/2011 09:14 PM, Sean O'Donnell wrote: > Hi all, > Hello Sean, > I checked the GIT repository and noticed that there was a patch in forward.c for > this issue. Looks like it was done 11/4/2010. Two questions: > > 1) Is there any reason that patch didn't make it into Kamailio 3.1.2 ? > Indeed, there is no reason. Actually I have cherry-picked the patches into the 3.1 branch (commit_notice 3.1 3ec1e9 and 9ef0a1e). Thanks for noticing. > 2) Any reason I shouldn't apply that patck to my 1.5.4 release? > The patch was already applied to the svn 1.5 branch (don't know if the latest 1.5.5 tar ball has it) but you can install it from svn and you can find it there (commit 6050) Cheers Marius > Thanks, > Sean O'Donnell > Senior Engineer > uReach Technologies, Inc. > > > > > > ---- On Thu, 10 Feb 2011, Sean O'Donnell (skodonnell(a)ureach.com) wrote: > > Hi all, > > I just started deploying Kamailio release 1.5.4, and I think there's an issue > with how Kamailio identifies an outgoing interface when mhomed is enabled under > Linux. > > I use Kamailio as a call distributor/proxy between a soft-switch/SBC and a > voicemail platform. It > runs on a CentOS 5.3 (Linux 2.6 kernel) host with two network interfaces and is > configured such that it listens on both interfaces. One interface (public > interface) handles traffic with the SBC, the other (private interface) handles > with the VM platform. The 'mhomed' option is enabled. > > After upgrading from 1.5.3 to 1.5.4, I started noticing problems with UDP > packets coming out of the public interface. After looking at some ngrep > captures on that interface, I noticed that some packets had the source IP > address of the private interface and also had Record-Route and Via headers for > the private interface only - no headers for the public interface were there. > > Usually when I see the wrong source IP in a UDP packet, it's an issue with how > routes are set up on the host. However, I had our network engineer double check > them, and they seem fine (no ambiguous routes). The fact that I captured these > messages on the public interface also indicates to me that the kernel is routing > the message correctly. The missing Record-Route and Via for the public > interface, however, lead me to believe that the proxy didn't correctly identify > the outgoing interface in the first place. > > After looking at the ChangeLog for 1.5.4, I noticed that the some new logic was > put in to improve performance when mhomed is enabled (r5971) in forward.c, and I > think this is the issue. > > As I understand it, prior to 1.5.4, when mhomed was enabled, Kamailio determined > the outgoing interface by creating a temporary UDP socket, invoking connect() on > the socket with the packet destination, then checking the source IP of the > socket that the kernel assigned using getsockname(). After the source address > was determined, the temp socket was closed closed. As of 1.5.4, this was > modified to reuse the temporary socket and just re-invoking connect() with a new > destination address. > > The problem with the enhancement is that Linux (again, at least in the 2.6 > kernels I'm using) > doesn't seem to rebind a new source address to the socket when connect() is > called more than once on > a UDP socket. Instead, it keeps the original one, and thus the wrong interface > is assumed. > > I wrote a small program to confirm this - basically creates a UDP socket, calls > connect()/getsockname() > multiple times using different destination addresses. I ran it on several 2.6 > kernels, including > Centos4.x and Centos5. The result was always that the source address of the > socket wasn't changed after the first connect(), regardless of the destination > address. The only way I could get it work as > required was to first do a connect() using a zero'd out AF_UNSPEC address before > doing the > connect() to the remote address. I also ran it on Solaris and it worked. Go > figure. > > I've downloaded the latest stable release (3.1.2) but I think the issue is still > there, and I don't see > anything in the user groups that addresses this. > > Any help would be appreciated. > > Thanks, > > Sean > > > _______________________________________________ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users(a)lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > > > > > _______________________________________________ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users(a)lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > > _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

2 1

Error when tring to load lcr module.
by Gary Chen 16 Feb '11

16 Feb '11

I am using Kamailio 3.1.2. I added lcr module in my kamailio.cfg file. After run this: ./kamctl -E I got this error: 0(23744) ERROR: lcr [lcr_mod.c:1235]: lcr_gw params at row <0> does not start with ';' 0 I have set up some gateway information in lcr_gw , lcr_rule and lcr_rule_target. From log it seems retrieve all the information but then got above error. Here is my lcr part of config: loadmodule "lcr.so" modparam("lcr", "db_url", DBURL) modparam("lcr", "gw_uri_avp", "$avp(i:709)") modparam("lcr", "ruri_user_avp", "$avp(i:500)") modparam("lcr", "flags_avp", "$avp(i:712)") Gary

2 1

Re: [SR-Users] pdb module timeouts
by Thomas Baumann 15 Feb '11

15 Feb '11

Hello, I did a fallback to the original source, without sucess. I still have massive timeouts. So far I have no idea, how to go on. ps. what lenght of the carrier codes would be ok ? 3...10 digits, additional characters needed like A,B,C,D,E,F? regards, Thomas Hi Henning, this change was done at pdbt.c: $ diff pdbt.c pdbt_changed.c 245c245 < bufsize = slen + 1 + 1 + 3 + 1 + 1; // line buff er (telephone number + colon + white space + carrier ID + newline + \0) --- > bufsize = slen + 1 + 1 + 4 + 1 + 1; // line buff er (telephone number + colon + white space + carrier ID + newline + \0) 257,258c257,258 < ret = snprintf(p, 5, "%d\n", node->carrier); < if (ret < 1 || ret > 4) { --- > ret = snprintf(p, 6, "%d\n", node->carrier); > if (ret < 1 || ret > 5) { If I run querys in filemode against the server, where is no timeout. pdbt query -f /tmp/numbers3 -r 10.12.18.21:10001 -q 1 | grep answer regards, Thomas -----Ursprüngliche Nachricht----- Von: "Henning Westerholt" <henning.westerholt(a)1und1.de> Gesendet: 11.02.2011 09:33:05 An: sr-users(a)lists.sip-router.org Betreff: Re: [SR-Users] pdb module timeouts On Wednesday 09 February 2011, Thomas Baumann wrote: > I am using the PDB module and server components for number portability. 2 > instances of PDB Server runs on (10.12.19.51/10001/10002), Kamailio on > (10.12.19.21). With a small amount of traffic (-cmax 150 -cps 10 > -callduration 3), where are timeouts: WARNING: pdb [pdb.c:260]: exceeded > timeout while waiting for response. > > One requested number was 307111094, where the module prints out a timeout. > > The funny part is, that I can see the responses at least arriving at the > 10.12.19.21 interface on time. > > Request send: 0,200855 s > Answer received: 0,201027 s > > That are 0,172 ms and far away from a timeout. > > What could be the reason ? Hi Thomas, a bit difficult to say on a first sight.. Maybe some scheduling or load issues on the local machine? I've just checked two production server here, i don't see it so far in the available logs. How much load do you've on the machine? And what kind of timeout value do you specified? > ps. A small change on the server part was done: handle 4 digit carrier > codes. Ah, i see. I guess its not a big change? Regards, Henning ___________________________________________________________ Schon gehört? WEB.DE hat einen genialen Phishing-Filter in die Toolbar eingebaut! http://produkte.web.de/go/toolbar

2 1

CORE postgres module
by Bruno Bresciani 15 Feb '11

15 Feb '11

Hi, During my tests with kamailio 1.5.0 a core is generated when postgres is disconnected and I try register a user or make a call in kamailio. Analising the module postgres source code I notice that core is generated by the PQescapeStringConn located in db_postgres_val2str function. Someone know why this core is generated? Best Regards

2 2

Issue with avp
by Amit Nepal 14 Feb '11

14 Feb '11

Hi, I have been trying to load rpid while loading credentials. modparam("auth_db", "load_credentials", "$avp(i:123)=rpid") Now, I am trying to do a check in my routing logic. xlog("L_NOTICE","The avp is :$avp(i:123)"); (I dont get the value here either, i can't see the value when i do avp_print() if($avp(i:123)<5) { sl_send_reply("408","Message Here"); } I dont get the value of avp at that place. Any guidance please. -- Thank You Amit Nepal Systems Administrator Phoenix Internet Phone: 602-385-0731 602-234-0917#112 http://www.phoenixinternet.net

2 4

kamailio 1.5.5 crashes continue
by Andrew O. Zhukov 14 Feb '11

14 Feb '11

Core was generated by `/usr/local/sbin/kamailio -P /var/run/openser/openser.pid -m 32 -u openser -g op'. Program terminated with signal 6, Aborted. #0 0x00000039d8c30265 in raise () from /lib64/libc.so.6 (gdb) backtrace #0 0x00000039d8c30265 in raise () from /lib64/libc.so.6 #1 0x00000039d8c31d10 in abort () from /lib64/libc.so.6 #2 0x000000000046c397 in qm_debug_frag (qm=0x733c00, f=0x841420) at mem/q_malloc.c:137 #3 0x000000000046d99a in qm_free (qm=0x733c00, p=0x841450, file=0x4e4d30 "parser/digest/digest.c", func=0x4e4da0 "free_credentials", line=95) at mem/q_malloc.c:439 #4 0x0000000000495fac in free_credentials (_b=0x2b875404a130) at parser/digest/digest.c:95 #5 0x0000000000471a36 in clean_hdr_field (hf=0x2b875404a100) at parser/hf.c:116 #6 0x00002b8750ab78de in clean_msg_clone (msg=0x2b8754049130, min=0x2b8754049130, max=0x2b875404a748) at sip_msg.h:54 #7 0x00002b8750ab77b7 in run_trans_callbacks (type=2, trans=0x2b8754057ec0, req=0x2b8754049130, rpl=0x7c0eb8, code=200) at t_hooks.c:245 #8 0x00002b8750abe39d in t_reply_matching (p_msg=0x7c0eb8, p_branch=0x7fffbe5d11e8) at t_lookup.c:888 #9 0x00002b8750abe997 in t_check (p_msg=0x7c0eb8, param_branch=0x7fffbe5d11e8) at t_lookup.c:964 #10 0x00002b8750acd79b in reply_received (p_msg=0x7c0eb8) at t_reply.c:1395 #11 0x000000000041c6db in forward_reply (msg=0x7c0eb8) at forward.c:576 #12 0x000000000043ccf0 in receive_msg ( buf=0x712980 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP XXX.XX.XXX.13;branch=z9hG4bK8aa9.93e271f1.0;received=XXX.XX.XXX.13\r\nVia: SIP/2.0/UDP XXX.XX.XXX.236:5060;received=XXX.XX.XXX.236;branch=z9hG4bK37dacff3;rport=5060\r\nRec"..., len=576, rcv_info=0x7fffbe5d1340) at receive.c:212 #13 0x00000000004692e3 in udp_rcv_loop () at udp_server.c:449 #14 0x0000000000420ecb in main_loop () at main.c:774 #15 0x0000000000422e0f in main (argc=11, argv=0x7fffbe5d15c8) at main.c:1321 (gdb) q [root@ tmp]# openser -V version: kamailio 1.5.5-notls (x86_64/linux) flags: STATISTICS, EXTRA_DEBUG, USE_IPV6, USE_TCP, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, PKG_SIZE 4194304 poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. svnrevision: unknown @(#) $Id: main.c 5608 2009-02-13 16:48:17Z henningw $ main.c compiled on 09:42:37 Feb 10 2011 with gcc 4.1.2 Andrew.

2 3