sr-users January 2014

sr-users@lists.kamailio.org

93 participants
141 discussions

Kamailio multi domain issue..
by arun Jayaprakash 16 Jan '14

16 Jan '14

Hello, I am using Kamailio with a multidomain set up. It is working well but for one issue: I first populate the /etc/hosts file with the domain name and the IP address ( and of course the domain table ) but the new domain does not take effect till I restart the kamailio. Does anyone know how I can overcome this problem as it is not possible for me to keep restarting the server each time a new user registers. Thanks for the help. Arun

2 3

Kamailio Advanced Training Course in Europe 2014?
by Yufei Tao 16 Jan '14

16 Jan '14

Hi Just a quick question about the Kamailio Advanced Training Course: are there any courses scheduled in Europe in 2014? If there are, roughly what time will they likely to take place? The only one I can find is the one in Miami next month but it's a bit far to travel. Cheers, Yufei -- Yufei Tao Red Embedded This E-mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message. You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender. Red Embedded Design, Company Number 06688253 Registered in England: The Waterfront, Salts Mill Rd, Saltaire, BD17 7EZ

1 0

Authenticate Failure
by Keith 16 Jan '14

16 Jan '14

Hi, Having a strange issue: auth_db [authorize.c:476]: auth_check(): realm [x.x.x.x] table [subscriber] flags [1] Sep 8 02:10:28 localhost /usr/sbin/kamailio[65448]: DEBUG: auth [api.c:86]: pre_auth(): auth:pre_auth: Credentials with realm 'x.x.x.x' not found Sep 8 02:10:28 localhost /usr/sbin/kamailio[65448]: DEBUG: auth_db [authorize.c:252]: digest_authenticate(): no credentials The x is replaced with my IP. The user was created with the IP address as the domain. Username and password are correct and the phone registers fine. It's just when I place a call it doesn't get routed properly. Thanks Keith

2 1

kamailio crash after sqlops failures
by Uri Shacked 16 Jan '14

16 Jan '14

Hi, Our system had crashed again. Here are the exact details and there are logs and corefile attached. We use 6 kamailio servers over 3 sites. All the servers are connecting to 1 DB server running MYSQL 5.6.12. The sql server supplies 2 things for kamailio servers. 1. Some SQLOPS that the servers need. 2. The data for the MTREE, HTABLE, CARRIERROUTE etc.. We use "kamctl" command in shell script to reload the data for the modules every 1 minute. In normal times, the reload takes about 2-3 sec each minute. When the sql server is down, the queries and reloads fail and it is OK. Yesterday, we had a different failure on the sql server – The server is set ona centos 6.2 that is under a VM cluster. The VM cluster had some disk writing errors, and the sql server could not write or read fast enough. On 3 of the 6 servers (one at each site) kamailio crashed. I have no idea why. When the sql server is down, it does not happen. I attached all 6 servers log, 1 server core file, 1 server var/log/messages and the mysql slow-query log. Any ideas how to handle this? kamailio version 3.3.2 BR, Uri

2 1

Daily crash of kamailio 4.0.5
by Tristan Mahé 15 Jan '14

15 Jan '14

Hi guys, I'm having some crashs on a simple REGISTRAR, in st_delete_ucontact. It happens daily, mostly when proxy is loaded. Saw that someone got the same problem via this pastebin: http://pastebin.com/GsMtav7A. Does someone got an idea of why it's failing or a workaround or a fix to share ? Here is the backtrace for us: #0 0x00007fb6d7178e3c in st_delete_ucontact (_c=0xf0) at ucontact.c:358 #1 0x00007fb6d718f4a1 in delete_ucontact (_r=0x7fb69c9a1ea0, _c=0xf0) at urecord.c:509 #2 0x00007fb6d6d49b6a in update_contacts (_m=0x7fb6d8e1ab70, _r=0x7fb69c9a1ea0, _mode=1) at save.c:700 #3 0x00007fb6d6d4a4c3 in add_contacts (_m=0x7fb6d8e1ab70, _d=0x7fb6908c2f10, _a=0x7fff02a69380, _mode=1) at save.c:803 #4 0x00007fb6d6d4a9f2 in save (_m=0x7fb6d8e1ab70, _d=0x7fb6908c2f10, _cflags=4, _uri=0x0) at save.c:879 #5 0x00007fb6d6d3e41d in w_save2 (_m=0x7fb6d8e1ab70, _d=0x7fb6908c2f10 "\240.\214\220\266\177", _cflags=0x4 <Address 0x4 out of bounds>) at reg_mod.c:442 #6 0x000000000041b80b in do_action (h=0x7fff02a699a0, a=0x7fb6d8de2a30, msg=0x7fb6d8e1ab70) at action.c:1086 #7 0x0000000000423f62 in run_actions (h=0x7fff02a699a0, a=0x7fb6d8de2a30, msg=0x7fb6d8e1ab70) at action.c:1573 #8 0x0000000000424639 in run_actions_safe (h=0x7fff02a6ae90, a=0x7fb6d8de2a30, msg=0x7fb6d8e1ab70) at action.c:1637 #9 0x00000000004bef7d in rval_get_int (h=0x7fff02a6ae90, msg=0x7fb6d8e1ab70, i=0x7fff02a69da8, rv=0x7fb6d8de37a8, cache=0x0) at rvalue.c:920 #10 0x00000000004c1b85 in rval_expr_eval_int (h=0x7fff02a6ae90, msg=0x7fb6d8e1ab70, res=0x7fff02a69da8, rve=0x7fb6d8de37a0) at rvalue.c:1914 #11 0x00000000004c1d6c in rval_expr_eval_int (h=0x7fff02a6ae90, msg=0x7fb6d8e1ab70, res=0x7fff02a6a200, rve=0x7fb6d8de30c0) at rvalue.c:1922 #12 0x000000000041b422 in do_action (h=0x7fff02a6ae90, a=0x7fb6d8df3700, msg=0x7fb6d8e1ab70) at action.c:1050 #13 0x0000000000423f62 in run_actions (h=0x7fff02a6ae90, a=0x7fb6d8de27f0, msg=0x7fb6d8e1ab70) at action.c:1573 #14 0x000000000041b661 in do_action (h=0x7fff02a6ae90, a=0x7fb6d8df3900, msg=0x7fb6d8e1ab70) at action.c:1065 #15 0x0000000000423f62 in run_actions (h=0x7fff02a6ae90, a=0x7fb6d8df3900, msg=0x7fb6d8e1ab70) at action.c:1573 #16 0x0000000000419851 in do_action (h=0x7fff02a6ae90, a=0x7fb6d8dc0e70, msg=0x7fb6d8e1ab70) at action.c:690 #17 0x0000000000423f62 in run_actions (h=0x7fff02a6ae90, a=0x7fb6d8db9bf0, msg=0x7fb6d8e1ab70) at action.c:1573 #18 0x0000000000424701 in run_top_route (a=0x7fb6d8db9bf0, msg=0x7fb6d8e1ab70, c=0x0) at action.c:1658 #19 0x00000000004a0018 in receive_msg ( buf=0x9055c0 "REGISTER sip:[ADOMAIN] SIP/2.0\r\nVia: SIP/2.0/UDP [ANIP];branch=z9hG4bKcydzigwkX;i=20be2b3\r\nVia: SIP/2.0/TLS [ANIP]:40080;received=[ANIP];rport=50419;branch=z9hG4bK793894041\r\nFr"..., len=613, rcv_info=0x7fff02a6b140) at receive.c:211 #20 0x0000000000530665 in udp_rcv_loop () at udp_server.c:557 #21 0x0000000000469be4 in main_loop () at main.c:1638 #22 0x000000000046ca85 in main (argc=13, argv=0x7fff02a6b478) at main.c:2566 And here is the simple part of config that could call this method: route[REGISTRAR] { if (is_method("REGISTER")) { if (!save("location","0x04")) { sl_reply_error(); } else { # DOSOMESTUFF like replicate to a backup proxy } exit; } } If you need more info, don't hesitate to ask !!

1 0

Link Redundancy
by Owais ul Haq 15 Jan '14

15 Jan '14

Hello, I have a kamailio server deployed along with an internet connection and database (on a seperate server than the kamailio server) obviously. Problem in my scenario is that my internet connection is not comfortably reliable and in my environment I just cant help myself in this regard. I want to get another internet connection with another public ip, attach another kamailio server (of same configurations as the first one) with it and then use the same database for both kamailio servers (join both kamailio servers to the same database server). So if one of my connections is down, calls can use other connection attached to other server (take the alternate path) and initialize through the second server. Now my questions are : a) How can I assign two ip's against one domain name ?? b) How can calls be routed to second IP if kamailio server attached to first IP is not responding ?? c) Is all this really possible ?? Or just a fruit less effort of my mind :( Cheers.

2 1

Re: [SR-Users] register fails from openvpn clients
by meres 15 Jan '14

15 Jan '14

Hello, Thank you for your help The REGISTER request is getting to kamailio. I attach my tcpdump output: http://pastebin.com/3RV9wG5G Regards, Kostas On Jan 15, 2014, at 11:09 AM, Daniel-Constantin Mierla <miconda(a)gmail.com> wrote: > Hello, > > what do you mean by "register fails"? > > Is the REGISTER request getting to kamailio? Is there a reply for it? > > A ngrep output taken on kamailio server for such registration would help to figure out where is the issue. > > Cheers, > Daniel > > On 13/01/14 18:08, meres wrote: >> I have kamailio 4.1.0 running on a server on a real ip and behind a firewall. >> NAT detection is enabled on kamailio because many remote clients are behind NAT, so NAT is working fine along with rtpproxy. >> Everything else (incoming, outgoing) is working fine except the following: >> >> Users who are connected to our openvpn server (bridged mode) which is on the same subnet with kamailio, fail to register. >> I suspect that kamailio detects NAT on these clients as all of them are behind NAT, but they also have obtained a real ip from our openvpn server on their tap interface and as a result, REGISTER fails. >> >> One solution, but not the best is to exclude kamailio from our openvpn routes but I would not prefer this because I wil not be able to manage the server remotely >> >> My config: http://pastebin.com/JSxzgmKH >> >> Any suggestions? >> >> >> >> >> _______________________________________________ >> 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 > > -- > Daniel-Constantin Mierla - http://www.asipto.com > http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda > _______________________________________________ > 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

3 5

Implementing the Presence module(Kamailio) to work with websockets (sipML5)
by אורן אברהם 15 Jan '14

15 Jan '14

Dear List, I have some strange error when using sipML5 client (over websockets) with Kamailio 4.0 server when sending a SUBSCRIBE request. here is my log print: Apr 18 02:55:21 oren-ubuntu /usr/sbin/kamailio[26476]: WARNING: <core> [msg_translator.c:2499]: TCP/TLS connection (id: 0) for WebSocket could not be found (tcp:10.0.0.4:8080) Apr 18 02:55:21 oren-ubuntu /usr/sbin/kamailio[26476]: ERROR: tm [t_msgbuilder.c:1367]: assemble_via: via building failed Apr 18 02:55:21 oren-ubuntu /usr/sbin/kamailio[26476]: ERROR: tm [t_msgbuilder.c:1540]: build_uac_req(): Error while assembling Via Apr 18 02:55:21 oren-ubuntu /usr/sbin/kamailio[26476]: ERROR: tm [uac.c:338]: t_uac: Error while building message Apr 18 02:55:21 oren-ubuntu /usr/sbin/kamailio[26476]: ERROR: presence [notify.c:1591]: in function tmb.t_request_within Apr 18 02:55:21 oren-ubuntu /usr/sbin/kamailio[26476]: ERROR: presence [notify.c:1678]: sending Notify not successful Apr 18 02:55:21 oren-ubuntu /usr/sbin/kamailio[26476]: ERROR: presence [subscribe.c:678]: Could not send notify Apr 18 02:55:21 oren-ubuntu /usr/sbin/kamailio[26476]: ERROR: presence [subscribe.c:713]: occured Apr 18 02:55:21 oren-ubuntu /usr/sbin/kamailio[26476]: ERROR: presence [subscribe.c:994]: in update_subscription Could anyone help here ? I think it is only some configuration problem, but i'm not sure how to solve it.

3 6

dispatcher sets - mixed/overlapping algorithm
by Rob Moore 15 Jan '14

15 Jan '14

Hi All, I've been trying to find the best way of providing a single dispatcher set to cover all of our outbound SIPtoPSTN providers. However in order to create a single dispatcher set I would need to have a mixture of the available algorithms to provide the required effect. So for example, if I have 4 providers, the first 2 have 2 IP addresses each and the other 2 only have a IP address each. As a standard I would use dispatcher algorithm "8 - use first destination" to move through the 4 providers IP address, 1 at a time as we have a preference of which provider we would like to be used first. However due to CPS and other throughput reasons we get better performance from our first two providers if we round-robin our requests over the two IP addresses for each provider. So What I'm trying to create is a list where I can : round-robin the 2 IPs from Provider1 if both Provider 1 IPs fail I can then.... round-robin the 2 IPs from Provider2 if both Provider 2 IPs fail I can then.... Dispatch calls to the single IP of Provider 3 If Provider 3 fails then.... Dispatch calls to the single IP of Provider 4 I'm, fairly certain that there isn't anything available straight out of the module for this but I'm not sure on how best to build this functionality in. Maybe I need to look at using multiple sets but hidden behind a single set ID. My main preference is that I want to keep all of the logic for this within Kamailio and have our telephony app servers simply dispatcher a call with a specified dispatcher ID as per usual. Other than this one caveat I'm really open to suggestions on how to fulfil this requirement. Any assistance will be greatly appreciated. Many Thanks Rob

1 0

S-CSCF configuration brings to seg fault
by Gennaro Sarnataro 15 Jan '14

15 Jan '14

hello everyone, I'm using some kamailio configurations to perform I-CSCF and S-CSCF. My configurations file let me register and unregister correctly. When i try to perform an invite I've a memory leak as you can see from this log: Jan 15 11:07:50 localhost kamailio[2873]: INFO: <script>: route: received > packet Jan 15 11:07:50 localhost kamailio[2873]: INFO: <script>: route: received > register Jan 15 11:07:50 localhost kamailio[2873]: INFO: ims_auth [authorize.c:663]: > authenticate(): uri=sip:ims.test.netnonce=173692b1aea9182c2ac712f915f0144a > response=f1efa37094e4492af1e292043c3d57ea qop=auth nc=00000001 > cnonce=a2f5a827ac94467a39e81584c11e8284 hbody= Jan 15 11:07:50 localhost kamailio[2873]: INFO: ims_auth [authorize.c:708]: > authenticate(): UE said: f1efa37094e4492af1e292043c3d57ea and we expect > f1efa37094e4492af1e292043c3d57ea ha1 1c31125e2929b3fd6a609bd1a134a631 > (REGISTER) Jan 15 11:07:50 localhost kamailio[2873]: INFO: ims_registrar_scscf > [cxdx_sar.c:79]: create_return_code(): created AVP successfully : > [saa_return_code] - [-2] Jan 15 11:07:50 localhost kamailio[2932]: INFO: ims_registrar_scscf > [cxdx_avp.c:138]: cxdx_get_avp(): cxdx_get_experimental_result_code: Failed > finding avp Jan 15 11:07:50 localhost kamailio[2932]: INFO: ims_registrar_scscf > [cxdx_sar.c:79]: create_return_code(): created AVP successfully : > [saa_return_code] - [1] Jan 15 11:07:50 localhost kamailio[2932]: WARNING: tm [t_lookup.c:1536]: > t_unref(): WARNING: script writer didn't release transaction Jan 15 11:08:05 localhost kamailio[2940]: ERROR: <script>: INVITE ( > sip:+393922568123@ims.test.net (10.139.140.249:14437) to > sip:+39666555@ims.test.net, > 0gQAAC8WAAACBAAALxYAAM3V1YJ1oc5VxmgXA6gfuMM+33iKMHHLO4FAjeWDRORBfoRu5acqCjeTKNa2pjdRdA--(a)10.139.140.249 > ) Jan 15 11:08:05 localhost kamailio[2940]: INFO: <script>: route: received > packet Jan 15 11:08:05 localhost kamailio[2940]: INFO: <script>: route: Mobile > Originating Side Jan 15 11:08:05 localhost kamailio[2940]: INFO: <script>: Routing Mobile > Originating side Jan 15 11:08:05 localhost kamailio[2940]: INFO: <script>: Adding angle > brackets to P-Asserted-Identity Jan 15 11:08:05 localhost kamailio[2940]: INFO: ims_isc [mod.c:236]: > isc_match_filter(): Checking triggers Jan 15 11:08:05 localhost kamailio[2940]: : <core> [mem/q_malloc.c:454]: > qm_free(): BUG: qm_free: bad pointer 0x7f3dc03597a0 (out of memory block!) > called from <core>: parser/parse_param.c: do_free_params(629) - aborting Jan 15 11:08:05 localhost kamailio[2943]: : <core> [pass_fd.c:293]: > receive_fd(): ERROR: receive_fd: EOF on 90 Jan 15 11:08:05 localhost kamailio[2863]: ALERT: <core> [main.c:775]: > handle_sigs(): child process 2940 exited by a signal 6 Jan 15 11:08:05 localhost kamailio[2863]: ALERT: <core> [main.c:778]: > handle_sigs(): core was generated Jan 15 11:08:05 localhost kamailio[2863]: INFO: <core> [main.c:790]: > handle_sigs(): INFO: terminating due to SIGCHLD Jan 15 11:08:05 localhost kamailio[2939]: INFO: <core> [main.c:841]: > sig_usr(): INFO: signal 15 received Jan 15 11:08:05 localhost kamailio[2942]: INFO: <core> [main.c:841]: > sig_usr(): INFO: signal 15 received > ..... > Jan 15 11:08:05 localhost kamailio[2942]: INFO: <core> [main.c:841]: > sig_usr(): INFO: signal 15 received Jan 15 11:08:05 localhost kamailio[2876]: INFO: <core> [main.c:841]: > sig_usr(): INFO: signal 15 received Jan 15 11:08:05 localhost kamailio[2863]: INFO: cdp [mod.c:251]: > cdp_exit(): CDiameterPeer child stopping ... Jan 15 11:08:05 localhost kamailio[2863]: INFO: cdp [diameter_peer.c:428]: > diameter_peer_destroy(): destroy_diameter_peer(): Terminating all > children... Jan 15 11:08:05 localhost kamailio[2863]: INFO: cdp [diameter_peer.c:435]: > diameter_peer_destroy(): destroy_diameter_peer(): Waiting for child [2939] > to terminate... Jan 15 11:08:05 localhost kamailio[2863]: INFO: cdp [diameter_peer.c:435]: > diameter_peer_destroy(): destroy_diameter_peer(): Waiting for child [2938] > to terminate... Jan 15 11:08:05 localhost kamailio[2863]: INFO: cdp [diameter_peer.c:435]: > diameter_peer_destroy(): destroy_diameter_peer(): Waiting for child [2937] > to terminate... Jan 15 11:08:05 localhost kamailio[2863]: INFO: cdp [diameter_peer.c:435]: > diameter_peer_destroy(): destroy_diameter_peer(): Waiting for child [2936] > to terminate... Jan 15 11:08:05 localhost kamailio[2863]: INFO: cdp [diameter_peer.c:435]: > diameter_peer_destroy(): destroy_diameter_peer(): Waiting for child [2935] > to terminate... Jan 15 11:08:05 localhost kamailio[2863]: INFO: cdp [diameter_peer.c:435]: > diameter_peer_destroy(): destroy_diameter_peer(): Waiting for child [2934] > to terminate... Jan 15 11:08:05 localhost kamailio[2863]: INFO: cdp [diameter_peer.c:435]: > diameter_peer_destroy(): destroy_diameter_peer(): Waiting for child [2933] > to terminate... Jan 15 11:08:05 localhost kamailio[2863]: INFO: cdp [diameter_peer.c:435]: > diameter_peer_destroy(): destroy_diameter_peer(): Waiting for child [2932] > to terminate... Jan 15 11:08:05 localhost kamailio[2863]: INFO: cdp [diameter_peer.c:447]: > diameter_peer_destroy(): destroy_diameter_peer(): All processes terminated. > Cleaning up. Jan 15 11:08:05 localhost kamailio[2863]: INFO: cdp [worker.c:137]: > worker_destroy(): Unlocking workers waiting on empty queue... Jan 15 11:08:05 localhost kamailio[2863]: INFO: cdp [worker.c:140]: > worker_destroy(): Unlocking workers waiting on full queue... Jan 15 11:08:05 localhost kamailio[2863]: CRITICAL: cdp > [diameter_peer.c:487]: diameter_peer_destroy(): destroy_diameter_peer(): > Bye Bye from C Diameter Peer test Jan 15 11:08:05 localhost kamailio[2863]: INFO: cdp [mod.c:253]: > cdp_exit(): ... CDiameterPeer child stoped after that the S-CSCF terminate. it's unuseful to attach any wireshark dump because,as I told before, the Serving process terminates just after receiving the INVITE. Instead I attach my configuration. thanks in advance!!! saluti Gennaro Sarnataro

2 1

← Newer
1
...
7
8
9
10
11
12
13
14
15
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 January 2014