sr-users

sr-users@lists.kamailio.org

48 participants
37555 discussions

Address already in use error when starting Kamailio service
by Mahmoud Ramadan Ali 03 Nov '14

03 Nov '14

Hiiiiii everyone, I'm receiving this error when starting Kamailio saying that it can not resolve my ip addresses used by Kamailio and another "127.0.0.1:5060 : Address already in use " error message...so how can i fix this please ? Nov 2 15:39:26 Kamailio /usr/local/sbin/kamailio[7692]: CRITICAL: <core> [pass_fd.c:293]: receive_fd(): EOF on 35 Nov 2 15:39:44 Kamailio kamailio: WARNING: <core> [socket_info.c:1392]: fix_hostname(): could not rev. resolve 192.168.100.1 Nov 2 15:39:44 Kamailio kamailio: WARNING: <core> [socket_info.c:1392]: fix_hostname(): could not rev. resolve 192.168.50.1 Nov 2 15:39:44 Kamailio kamailio: WARNING: <core> [socket_info.c:1392]: fix_hostname(): could not rev. resolve 192.168.100.1 Nov 2 15:39:44 Kamailio kamailio: WARNING: <core> [socket_info.c:1392]: fix_hostname(): could not rev. resolve 192.168.50.1 Nov 2 15:39:44 Kamailio /usr/local/sbin/kamailio[7726]: ERROR: <core> [tcp_main.c:2876]: tcp_init(): bind(b, 0x7faebd135ca4, 16) on 127.0.0.1:5060 : Address already in use

3 3

Kamailio behind NAT - Wrong VIA Header
by Marko Seidenglanz 03 Nov '14

03 Nov '14

Hello, We are using Kamailio 4.2 and RTPEngine 3.3 hosted on a VM behind NAT in Google Cloud Engine. Asterisk 11 + Kamailio + RTPEngine are on the same machine and Kamailio is used as WebRTC Gateway. INVITES, that are rewritten by Kamailio look like the following: INVITE sip:eTden7KoNSdMVCUNYIwmz@wh2.24dial.com SIP/2.0 Record-Route: <sip:0.0.0.0:5064;lr=on;nat=yes> Via: SIP/2.0/UDP 0.0.0.0:5064 ;branch=z9hG4bK86f5.88fb7f8810c91758b5f3962420d3a4ef.0 Via: SIP/2.0/UDP 10.240.1.95:5060 ;received=127.0.0.1;branch=z9hG4bK05952ee6;rport=5060 Max-Forwards: 69 From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=as7900b63f To: <sip:eTden7KoNSdMVCUNYIwmz@wh2.24dial.com> Contact: <sip:anonymous@10.240.1.95:5060;alias=127.0.0.1~5060~1> Call-ID: 0662d336694c60ed60ed5310571a1aee@10.240.1.95:5060 CSeq: 102 INVITE User-Agent: Asterisk PBX 11.13.1 Date: Mon, 03 Nov 2014 09:01:39 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer Content-Type: application/sdp Content-Length: 676 P-hint: outbound As you can see, Kamailio uses 0.0.0.0 for Record-Route as well as for VIA Header. It uses the address configured in kamilio.cfg (listen=udp:0.0.0.0:5064) I know, that we could use the advertise parameter to tell kamailio the external IP. The problem is, that IPs in GCE are dynamically assigned to the VMs. Thus static configuration of external IP is not sufficient for our setup. Is there a way, to let Kamailio gather it's external IP dynamically. (E.g. using a STUN server or something like that?) Another possibility would be to tell Kamailio it's external IP via a start parameter. Is that possible? Any help would be grateful. Kind regards, Marko Seidenglanz

2 1

using time stamp
by bob sacamano 03 Nov '14

03 Nov '14

hi, I am trying to see how long kamailio takes to process messages I saw the commands: set_time_stamp diff_time_stamp in older versions of kamailio but they dont seem to be available. I have been searching for info but have been unable to find anything. Is the command no longer available or is there some other way to use? thanks

2 3

FIFO Error When Running Kamctl dispatcher reload
by Mahmoud Ramadan Ali 02 Nov '14

02 Nov '14

Hiiiii Everyone I have encountered that error whenever i try to use the #Kamctl dispatcher reload even thought that i have the "modparam("mi_fifo", "fifo_name", "/tmp/kamailio_fifo")" and loadmodule "mi_fifo.so" configured...any ideas how to solve this issue ?! root@Kamailio:/usr/local/etc/kamailio# kamctl dispatcher reload ERROR: Error opening Kamailio's FIFO /tmp/kamailio_fifo ERROR: Make sure you have the line 'modparam("mi_fifo", "fifo_name", "/tmp/kamailio_fifo")' in your config ERROR: and also have loaded the mi_fifo module.

2 1

Re: [Kamailio-Users] /usr/local/sbin/kamdbctl create error
by vivi 01 Nov '14

01 Nov '14

Hi all.. I have solve the problem . Cheers, vivi From: vivi [mailto:vivi.hilton@gmail.com] Sent: Saturday, June 06, 2009 11:29 PM To: 'users(a)lists.kamailio.org' Subject: /usr/local/sbin/kamdbctl create error Hi all I have specify the wanted db type (DBENGINE=MYSQL) in the /usr/local/etc/kamailio/kamctlrc then I using "/usr/local/sbin/kamdbctl create" to create MySQL database, but I got this error: ERROR: database engine not specified, please setup one in the config script root@acer:/usr/local/src/kamailio-1.5.0/sip-server# vim /usr/local/etc/kamailio/kamctlrc root@acer:/usr/local/src/kamailio-1.5.0/sip-server# /usr/local/sbin/kamdbctl create MySQL password for root: INFO: test server charset ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. /usr/local/lib/kamailio/kamctl/kamdbctl.mysql: line 112: [: =: unary operator expected INFO: creating database openser ... ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) ERROR: Creating core database and grant privileges failed! Cheers, vivi

2 1

Trouble with LCR removing $ru after upgrading to 4.1.6
by Will Ferrer 01 Nov '14

01 Nov '14

Hi We are having an odd issue with our LCR. This started after we upgraded from kamailio 4.1.0 to 4.1.6. Here is the situation: We populate our gw_uri_avp (stored in: $avp(i:709)) as follows: 16|1||||[gateway ip address]||5060||1|1. The $ru before running next gateway shows: sip:[destination number]@[our domain that the call came into]. This is how it should look before lcr occurs. Then we run next_gw(). We get these message in the logs during the running of next_gw DEBUG: lcr [lcr_mod.c:2156]: generate_uris(): r_uri <*1*[destination number]@[gateway ip address]:5060*1*>, dst_uri <> DEBUG: lcr [lcr_mod.c:2437]: next_gw(): added ruri_user_avp <[destination number]> DEBUG: lcr [lcr_mod.c:2473]: next_gw(): added flags_avp <1> DEBUG: lcr [lcr_mod.c:2480]: next_gw(): added tag_avp <> DEBUG: lcr [lcr_mod.c:2488]: next_gw(): added defunct_gw_avp <1253613379> The main thing to notice there is that there is now a 1 at the start and end of the r_uri shown in generate_uris. I am fairly certain those are new, and maybe related to what happens next. Immediately following the next_gw function running the $ru becomes: <null>, so of course the call doesn't go through. I have looked at the code for the lcr module and it looks like it wasn't changed in version 4.1.6. I found alot of other notes in the change log that had to do with the way uris are handled so it is possible one of those changes caused the problem. I am stumped currently. Any help any one can offer me would be very appreciated. All the best. Will Ferrer Swithsoft Inc

2 4

Installing rtpengine on CentOS 6.5
by Juan Perez 31 Oct '14

31 Oct '14

Using Kamailio 4.2, CentOS 6.5, as per the documentation here: https://github.com/sipwise/rtpengine "Running make will compile the binary, which will be called rtpengine." When trying to install rtpengine I got the following error when building "daemon" [root@ip-10-0-2-68 daemon]# make Usage: awk [POSIX or GNU style options] -f progfile [--] file ... Usage: awk [POSIX or GNU style options] [--] 'program' file ... POSIX options: GNU long options: -f progfile --file=progfile -F fs --field-separator=fs -v var=val --assign=var=val -m[fr] val -O --optimize -W compat --compat -W copyleft --copyleft -W copyright --copyright -W dump-variables[=file] --dump-variables[=file] -W exec=file --exec=file -W gen-po --gen-po -W help --help -W lint[=fatal] --lint[=fatal] -W lint-old --lint-old -W non-decimal-data --non-decimal-data -W profile[=file] --profile[=file] -W posix --posix -W re-interval --re-interval -W source=program-text --source=program-text -W traditional --traditional -W usage --usage -W use-lc-numeric --use-lc-numeric -W version --version To report bugs, see node `Bugs' in `gawk.info', which is section `Reporting Problems and Bugs' in the printed version. gawk is a pattern scanning and processing language. By default it reads standard input and writes standard output. Examples: gawk '{ sum += $1 }; END { print sum }' file gawk -F: '{ print $1 }' /etc/passwd Makefile:88: .depend: No such file or directory make: *** No rule to make target `aux.c', needed by `.depend'. Stop. [root@ip-10-0-2-68 daemon]# I was able to build the iptables-extension, the kernel failed because I dont have the dependencies but the daemon is required. I think that I have all the dependencies: [root@ip-10-0-2-68 daemon]# rpm -qa | egrep "pcre|pkgconfig|xml|glib|zlib|openssl|curl" openssl-1.0.1e-30.el6_6.2.x86_64 glibc-common-2.12-1.132.el6_5.4.x86_64 zlib-1.2.3-29.el6.x86_64 curl-7.19.7-37.el6_5.3.x86_64 glibc-devel-2.12-1.132.el6_5.4.x86_64 libcurl-devel-7.19.7-37.el6_5.3.x86_64 openssl-devel-1.0.1e-30.el6_6.2.x86_64 glibc-2.12-1.132.el6_5.4.x86_64 pcre-7.8-6.el6.x86_64 libxml2-2.7.6-14.el6_5.2.x86_64 libcurl-7.19.7-37.el6_5.3.x86_64 python-pycurl-7.19.0-8.el6.x86_64 pkgconfig-0.23-9.1.el6.x86_64 glib2-2.26.1-7.el6_5.x86_64 dbus-glib-0.86-6.el6.x86_64 glibc-headers-2.12-1.132.el6_5.4.x86_64 zlib-devel-1.2.3-29.el6.x86_64 libxml2-devel-2.7.6-14.el6_5.2.x86_64 pcre-devel-7.8-6.el6.x86_64 [root@ip-10-0-2-68 daemon]# Am I missing something here?, thank you jp

2 4

pipelimit rate question
by Alex Balashov 31 Oct '14

31 Oct '14

Hi, There does not seem to be a way to update the limits of pipes dynamically. If I don't use DB backing, there is no MI/RPC command to flush existing pipes and cause them to be recreated with reconstituted limits. If I use DB backing and add pipes to the pl_pipes table, an SQL update to the limit column does not influence existing pipes that have been loaded from the DB on startup. Am I missing something, or does the existing feature set of the module simply not allow this? Thanks, -- Alex Balashov - Principal Evariste Systems LLC Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/ Please be kind to the English language: http://www.entrepreneur.com/article/232906

2 4

async workers causing unexplained high load average
by Alex Balashov 31 Oct '14

31 Oct '14

Another thing I have found is that having a certain amount of async workers running, even if they are not doing anything, appears to cause unexplained CPU load, even if the Kamailio instance is completely idle and not processing any calls. Here is the baseline load with no async workers: [root@centosity6 ~]# uptime 14:06:28 up 2 min, 2 users, load average: 0.01, 0.00, 0.00 If I start Kamailio with 1 async worker... modparam("async", "workers", 1) async_workers=1 14:07:59 up 3 min, 2 users, load average: 0.00, 0.00, 0.00 Still nothing. Now I try 2: 14:08:54 up 4 min, 2 users, load average: 0.45, 0.11, 0.04 14:08:59 up 4 min, 2 users, load average: 0.49, 0.12, 0.04 14:09:04 up 4 min, 2 users, load average: 0.53, 0.14, 0.04 14:09:09 up 4 min, 2 users, load average: 0.57, 0.15, 0.05 14:09:14 up 5 min, 2 users, load average: 0.60, 0.17, 0.05 14:09:19 up 5 min, 2 users, load average: 0.63, 0.18, 0.06 14:09:31 up 5 min, 2 users, load average: 0.69, 0.21, 0.07 14:09:37 up 5 min, 2 users, load average: 0.71, 0.22, 0.07 14:10:35 up 6 min, 2 users, load average: 0.89, 0.36, 0.13 14:11:07 up 6 min, 2 users, load average: 0.93, 0.42, 0.16 ... I don't have time right now to see if it will rise to infinity, but it just keeps going up. There are no SIP messages being received at all, and there is absolutely nothing going on. The ascent of the load average is much higher with >= 4 threads. I have 8 "CPUs" available from /proc/cpuinfo (quad-core processor with HyperThreading). When I attach strace to the PID of the Async Worker, there's nothing going on except the normal recvfrom() blocking wait: [root@centosity6 kamailio]# kamctl ps | grep Async which: no greadlink in (/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin:/) Process:: ID=11 PID=1559 Type=Async Task Worker Process:: ID=12 PID=1560 Type=Async Task Worker [root@centosity6 kamailio]# strace -p 1559 Process 1559 attached - interrupt to quit recvfrom(9, [root@centosity6 ~]# strace -p 1560 Process 1560 attached - interrupt to quit recvfrom(9, Nor do the other Kamailio threads seem to be doing anything unusual. 'ps aux' and 'top' show 0.0% CPU load on the Kamailio processes themselves, and 'iowait' shows the system as 98-99% idle. I suppose it's possible that this is a peculiarity of the testing environment: I am running this on CentOS 6.5 inside VirtualBox, which I think is KVM-based. I have not had a chance to duplicate this experiment in a different kind of execution environment yet. It's possible that the load average is simply being improperly indicated because of the VM environment. -- Alex Balashov - Principal Evariste Systems LLC Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/ Please be kind to the English language: http://www.entrepreneur.com/article/232906

2 6

append_hf on kamctl fifo dlg_bridge destroys ACK
by Kristian F. Høgh 31 Oct '14

31 Oct '14

Hi, Tested on 4.0.6 (+contact header REFER patch) and trunk. When appending header on originating INVITE, the ACK from kamailio gets messed up. I generate call, using myself as proxy kamctl fifo dlg_bridge sip:201@[domain] sip:202@[domain] sip:[kamailio-ip]:5060 In route[tm:local-request], i use append_hf("P-Asserted-Identity:...") If I remove append_hf, the ACK looks OK. Regards, Kristian Høgh Trace on local interface: INVITE sip:201@[domain] SIP/2.0 Via: SIP/2.0/UDP [kamailio-ip];branch=z9hG4bK9d54.ef433c83000000000000000000000000.0 To: <sip:201@[domain]> From: <sip:controller@kamailio.org>;tag=760f7752be879bf1a1346b149d21b85f-8c89 CSeq: 10 INVITE Call-ID: 0b4f5d725846cc40-12109@[kamailio-ip] Max-Forwards: 70 Content-Length: 147 User-Agent: kamailio Contact: <sip:controller@kamailio.org:5060> Content-Type: application/sdp P-Asserted-Identity: <sip:201@[domain]> <snip SDP> SIP/2.0 200 OK Via: SIP/2.0/UDP [kamailio-ip];rport=5060;branch=z9hG4bK9d54.ef433c83000000000000000000000000.0 Record-Route: <sip:[kamailio-ip];lr;ftag=760f7752be879bf1a1346b149d21b85f-8c89;vsf=AAAAAFFfXzREVlRVXUR1WU8dAxFCHAFHQgYCbC5kaw--;did=abe.bd12> Contact: <sip:201@[peer-ip]:43017;rinstance=50924dd7a7927b2f;transport=UDP> To: <sip:201@[domain]>;tag=594df15d From: <sip:controller@kamailio.org>;tag=760f7752be879bf1a1346b149d21b85f-8c89 Call-ID: 0b4f5d725846cc40-12109@[kamailio-ip] CSeq: 10 INVITE Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE Content-Type: application/sdp Supported: replaces, norefersub, extended-refer, timer, X-cisco-serviceuri User-Agent: Z 3.0.19649 r19608 Allow-Events: presence, kpml Content-Length: 157 <snip SDP> ACK sip:201@[peer-ip]:43017;rinstance=50924dd7a7927b2f;transport=UDP SIP/2.0 Via: SIP/2.0/UDP [kamailio-ip];branch=z9hG4bK9d54.ef433c83000000000000000000000000.0 \0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00P\0xeeu\0x00\0x00\0x00\0x00\0x00$\0x12v\0x00\0x00\0x00\0x00\0x00\0xbb\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0xf0\0xf0\0xf0\0xf0\0x00\0x00\0x00\0x00\0x16\0x0075\0x13\0x01\0x00\0x00X\0xfc\0xc2Vk\0x7f\0x00\0x00\0x00\0xfd\0xc2Vk\0x7f\0x00\0x00\0x0a\0x00\0x00\0x00f-8c\0x0b\0xfd\0xc2Vomain\0x00<domain>\0x009@178X\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00To: <sip:201@[domain]>;tag=594df15d k\0x7f\0x00\0x00\0x17\0x00\0x00\0x00 ACK Route: <sip:[kamailio-ip];lr;ftag=760f7752be879bf1a1346b149d21b85f-8c89;vsf=AAAAAFFfXzREVlRVXUR1WU8dAxFCHAFHQgYCbC5kaw--;did=abe.bd12> User-Agent: kamailio Content-Length: 0 REFER ...

2 4

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