[SR-Users] Kamailio with Asterisk 13 PjSip Realtime
Hi, I saw Matt Jordan's recent Kamailio world talk and was interested in the idea he proposed of stripling out authentication and registration from asterisk and solely letting Kamailio handle it. In order to do this would I be correct in assuming I would have to use the asterisk database rather than the Kamailio database? I've compared the two and the table structures are very different. If I use the asterisk database I guess asterisk still needs to be responsible for handling authentication, registration and writing the contacts to the database. If I use the Kamailio database how would I dial an extension from asterisk, because as far as I can fell asterisk will have no idea who is registered or how to find them (contact details). Maybe I'm over thinking something simple, or maybe I'm not. Either way I would love your thoughts on how this could be done. Kind regards, C ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Possible memory leak dealing with presence in kamailio
Hi Kristian and Daniel. Kristian, hhanks for you feedback and patch. I'll try your patch here and will let you know the outcome soon. Thanks again guys. Cheers, -- *Nuno Miguel Reis* | *Unified Communication** Systems* M. +351 913907481 | nr...@wavecom.pt WAVECOM-Soluções Rádio, S.A. Cacia Park | Rua do Progresso, Lote 15 3800-639 AVEIRO | Portugal T. +351 309 700 225 | F. +351 234 919 191 *GPS http://maps.google.com/maps/ms?msa=0msid=202333747613191340808.0004b4b227a6144f0df88 | www.wavecom.pt http://www.wavecom.pt/** http://www.wavecom.pt/* [image: Description: Description: WavecomSignature] http://www.wavecom.pt/pt/wavecom/premios.php [image: Publicity] http://www.wavecom.pt/pt/mail_eventos.php On Tue, Jan 13, 2015 at 10:00 AM, Daniel-Constantin Mierla mico...@gmail.com wrote: Hello, thanks for the details and patch. I will try to look at later today. Cheers, Daniel On 13/01/15 08:35, Kristian F. Høgh wrote: Hi, I've been hunting a memory error in publish handling the last couple of days. The error is on our old but good 3.1.x presence server. Using memory debug, I located the memory leak in modules/presence/hash.c, function insert_phtable, line 492 (in trunk): p= (pres_entry_t*)shm_malloc(size); As far I can see there are two errors when deleting publish htable entries 1. When calling delete_phtable pres.event-type is used instead of pres.event-evp-type 2. When creating publish hashtable, p-publ_count is not set. (defaults to 0) In delete_phtable, the following code is present p-publ_count--; if(p-publ_count== 0) p-publ_count is probably decremented to -1 (unless the user have two active dialogs) I attach a patch, which I would carefully test in a test environment :-) Regards, Kristian Høgh Uni-tel On Monday 12 January 2015 15:39:27 Nuno Reis wrote: Hello all. I'm consistently watching a memory increase in kamailio when dealing with PRESENCE events, namely SIP PUBLISH events. The system eventually hangs running out of memory. This behavior is seen at least in kamailio 4.1 and 4.2. I'm currently using the latest stable 4.2.2. If I disable the SIP PUBLISH handling in kamailio i don't observe the issue anymore but as a side effect I don't have presence (name BLFs) also. What do you think can be the right approach here? Should I open an issue in github for this? Should I run kamailio under valgrind for some time? Are there any other possible debug hints here? Please find attached a code snippet with the presence related parts I'm using right now. Looking forward to hear from you. Best Regards, -- *Nuno Miguel Reis* | *Unified Communication** Systems* M. +351 913907481 | nr...@wavecom.pt WAVECOM-Soluções Rádio, S.A. Cacia Park | Rua do Progresso, Lote 15 3800-639 AVEIRO | Portugal T. +351 309 700 225 | F. +351 234 919 191 *GPS http://maps.google.com/maps/ms?msa=0msid=202333747613191340808.0004b4b227a6144f0df88 http://maps.google.com/maps/ms?msa=0msid=202333747613191340808.0004b4b227a6144f0df88 | www.wavecom.pt http://www.wavecom.pt/ http://www.wavecom.pt/** http://www.wavecom.pt/ http://www.wavecom.pt/* [image: Description: Description: WavecomSignature] http://www.wavecom.pt/pt/wavecom/premios.php http://www.wavecom.pt/pt/wavecom/premios.php [image: Publicity] http://www.wavecom.pt/pt/mail_eventos.php http://www.wavecom.pt/pt/mail_eventos.php ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-us...@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users -- Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Dispatcher Failover algorithm
Daniel. I added 8 algorithm to our server and it works with 2 servers now
but it works strange because:
While works server with priority 1 - all ok. When this server goes down
dispatcher choose next server with lowes priority. But when server with
highest priority waking up dispatcher use server with lowes priority until
this server not goes down.
2015-01-12 15:18 GMT+03:00 Yuriy Gorlichenko ovoshl...@gmail.com:
Daniel. Hello. I see changes at documentation about algorithms at 4.3
documentation for dispatcher. Now I see than 8 algo use priority. Not I set
this algorithm to my servers but priority still not worked.
my dispatcher settings Are
modparam(dispatcher, db_url,DBURL)
modparam(dispatcher, table_name, dispatcher)
modparam(dispatcher, setid_col, setid)
modparam(dispatcher, priority_col, priority)
modparam(dispatcher, destination_col, destination)
modparam(dispatcher, force_dst, 1)
modparam(dispatcher, flags, 3)
modparam(dispatcher, dst_avp, $avp(i:271))
modparam(dispatcher, grp_avp, $avp(i:272))
modparam(dispatcher, cnt_avp, $avp(i:273))
modparam(dispatcher, ds_ping_from, sip:kamailio1@10.0.1.12)
modparam(dispatcher, ds_ping_interval,15)
modparam(dispatcher, ds_probing_mode, 1)
modparam(dispatcher, ds_ping_reply_codes,
class=2;code=403;code=404;code=484;class=3)
modparam(tm, reparse_on_dns_failover, 0)
(!ds_select_dst($var(setid), 8)){
sl_send_reply(500, Service Unavailable);
xlog(L_INFO,{$rm} from [$fU@$si:$sp] But NO destinations
available for $rd \n);
t_on_failure(DISPATCHER_ROLLOVER);
}
if (!t_relay()) {
sl_reply_error();
2015-01-10 2:31 GMT+03:00 Yuriy Gorlichenko ovoshl...@gmail.com:
Priority bassed? I've read about all algorithms of disatcher and can not
find that anone use priority...
-
“0” - hash over callid
-
“1” - hash over from URI.
-
“2” - hash over to URI.
-
“3” - hash over request-URI.
-
“4” - round-robin (next destination).
-
“5” - hash over authorization-username (Proxy-Authorization or
normal authorization). If no username is found, round robin is used.
-
“6” - random (using rand()).
-
“7” - hash over the content of PVs string. Note: This works only when
the parameter hash_pvar is set.
-
“8” - use first destination (good for failover).
-
“9” - use weight based load distribution. You have to set the
attribute 'weight' per each address in destination set.
-
“10” - use call load distribution. You have to set the attribute
'duid' (as an unique string id) per each address in destination set. Also,
you must set parameters 'dstid_avp' and 'ds_hash_size'.
The algorithm can be used even with stateless proxy mode, there is no
SIP dialog tracking depending on other modules, just an internal
lightweight call tracking by Call-Id, thus is fast and suitable even for
embedded systems.
The first destination selected by this algorithm is the one that has
the least number of calls associated. The rest of the destination list is
taken in order of the entries in set - anyhow, until a re-route to next
destination happens, the load on each address can change.
This algorithm can be used only for dispatching INVITE requests as it
is the only SIP method creating a SIP call.
-
“X” - if the algorithm is not implemented, the first entry in set is
chosen.
2015-01-09 20:23 GMT+03:00 Daniel-Constantin Mierla mico...@gmail.com:
You probably look for priority based routing -- see the readme of
dispatcher module.
Cheers,
Daniel
On 09/01/15 17:52, Yuriy Gorlichenko wrote:
I as wrote before - we find dispatcher algorithm than can do mechanism
something like this:
Try call to fist server with max priority or weight. OIf this server
unavailible then call second server with less weight and etc.
Does anyone know what ling of algorithm we can use for this?
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
listsr-us...@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierlahttp://twitter.com/#!/miconda -
http://www.linkedin.com/in/miconda
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@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@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] pua_subscribe and force_send_socket trouble
On 13/01/15 00:28, Mikko Lehto wrote: Juha Heinanen j...@tutpro.com: in case of tcp (and tls) the source port is always a random one. only the destination port can be predetermined. OK, thanks. I'll go with that then. Actually I can see non-random port with TLS... ...but that's with Homer + sip_trace() captured traffic. I'll write another thread about that. I checked the code and there is a bind() to local socket before doing tcp connect(). That should preserve the source port of the local address (socket) Kamailio is listening on. However, it is not guaranteed that the OS can do that, if there is an overlap on (source ip, source port, destination ip, destination port) with another connection. From the code, a warning message should be printed in logs. It also depends on OS and kernel versions. Apparently next link is a good article about (didn't have time to read it all): - https://idea.popcount.org/2014-04-03-bind-before-connect/ Cheers, Daniel -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Possible memory leak dealing with presence in kamailio
Hello, thanks for the details and patch. I will try to look at later today. Cheers, Daniel On 13/01/15 08:35, Kristian F. Høgh wrote: Hi, I've been hunting a memory error in publish handling the last couple of days. The error is on our old but good 3.1.x presence server. Using memory debug, I located the memory leak in modules/presence/hash.c, function insert_phtable, line 492 (in trunk): p= (pres_entry_t*)shm_malloc(size); As far I can see there are two errors when deleting publish htable entries 1. When calling delete_phtable pres.event-type is used instead of pres.event-evp-type 2. When creating publish hashtable, p-publ_count is not set. (defaults to 0) In delete_phtable, the following code is present p-publ_count--; if(p-publ_count== 0) p-publ_count is probably decremented to -1 (unless the user have two active dialogs) I attach a patch, which I would carefully test in a test environment :-) Regards, Kristian Høgh Uni-tel On Monday 12 January 2015 15:39:27 Nuno Reis wrote: Hello all. I'm consistently watching a memory increase in kamailio when dealing with PRESENCE events, namely SIP PUBLISH events. The system eventually hangs running out of memory. This behavior is seen at least in kamailio 4.1 and 4.2. I'm currently using the latest stable 4.2.2. If I disable the SIP PUBLISH handling in kamailio i don't observe the issue anymore but as a side effect I don't have presence (name BLFs) also. What do you think can be the right approach here? Should I open an issue in github for this? Should I run kamailio under valgrind for some time? Are there any other possible debug hints here? Please find attached a code snippet with the presence related parts I'm using right now. Looking forward to hear from you. Best Regards, -- *Nuno Miguel Reis* | *Unified Communication** Systems* M. +351 913907481 | nr...@wavecom.pt WAVECOM-Soluções Rádio, S.A. Cacia Park | Rua do Progresso, Lote 15 3800-639 AVEIRO | Portugal T. +351 309 700 225 | F. +351 234 919 191 *GPS http://maps.google.com/maps/ms?msa=0msid=202333747613191340808.0004b4b227a6144f0df88 | www.wavecom.pt http://www.wavecom.pt/** http://www.wavecom.pt/* [image: Description: Description: WavecomSignature] http://www.wavecom.pt/pt/wavecom/premios.php [image: Publicity] http://www.wavecom.pt/pt/mail_eventos.php ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Redirect Server Including Path/Recieved Information
On 12/01/15 13:14, Alex Hermann wrote: On Monday 12 January 2015, Daniel-Constantin Mierla wrote: On 09/01/15 15:41, Ben Langfeld wrote: For the ease of future reference, it would appear that post was http://sr-dev.sip-router.narkive.com/bfyDpQ36/git-alexh-master-core-modu les-tm-modules-sl-make-adding-path-and-flags-to-redirected-contacts#post4 Was this merged or discarded? Trying to look at the commit with the hash id from the archive doesn't work. I kept them local due to the perceived lack of interest. The link above shows the summary of a commit with git.sip-router.org url. But taking the commit id from there, didn't listed and patch with git log. Most of the individual patches are still in the sr-dev archive somewhere. They won't apply cleanly to 4.x. If there is interest now, i'll port and commit them when my setup eventually migrates to 4.x. The summary showed that many modules (including important ones like tm) and core were affected. If you port, make a commit/patch per component to be easy to review. Cheers, Daniel -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] TLS capture with sip_trace()
Hello, On 13/01/15 00:30, Mikko Lehto wrote: Hi I am getting incorrect source port to Homer web while tracking outgoing request from my proxy to remote SIP server. Juha Heinanen j...@tutpro.com wrote in another thread: in case of tcp (and tls) the source port is always a random one. only the destination port can be predetermined. Interface capture (tcpdump) shows exactly what Juha wrote i.e. random source port for TLS connection. I always get local TLS listener address as Homer source_port, clearly not true when comparing to output of tcpdump. I am calling sip_trace() from branch_route and onsend_route. Is it even possbile to use siptrace with TLS so that it records correct TCP (random) source port to Homer? I tried briefly printing some structure variables in siptrace/siptrace.c but it seems that real source port is not available in struct dest_info at that context. I guess siptrace is taking the details from sip msg structure at a time before tcp connect(), which can happen later if async tcp is enabled. It shows intended local socket for sending. Cheers, Daniel -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio 4.2.1 crashes on using exec_msg (also 4.2.2)
Hi again Daniel, We've upgraded to 4.2.2 and the recent changes in exec seem to still affect our usage of exec. From new coredump on 4.2.2: (gdb) bt #0 0x7f1c34dc404b in memcpy (__len=18446744073709551614, __src=0x7f1c2d4ecc09, __dest=0x7f1c368f4be2) at /usr/include/x86_64-linux-gnu/bits/string3.h:52 #1 print_hf_var (w=optimized out, offset=optimized out) at exec_hf.c:263 #2 print_var (w=optimized out, offset=optimized out) at exec_hf.c:296 #3 create_vars (list=optimized out, offset=optimized out) at exec_hf.c:346 #4 set_env (msg=0x7f1c368f4a08) at exec_hf.c:544 #5 0x7f1c34dc6835 in w_exec_msg (msg=0x7f1c36839480, cmd=0x7f1c3692b298 , foo=optimized out) at exec_mod.c:164 #6 0x004275d7 in do_action (h=h@entry=0x7fffdcd30740, a=a@entry=0x7f1c3692a9c0, msg=msg@entry=0x7f1c36839480) at action.c:1094 #7 0x00426289 in run_actions (h=h@entry=0x7fffdcd30740, a=a@entry=0x7f1c3692a9c0, msg=msg@entry=0x7f1c36839480) at action.c:1583 #8 0x00432a90 in run_top_route (a=0x7f1c3692a9c0, msg=msg@entry=0x7f1c36839480, c=c@entry=0x0) at action.c:1669 #9 0x7f1c365cdd9a in run_failure_handlers (t=t@entry=0x7f1c2d4f9d68, rpl=0x7f1c3693b0c0, code=486, extra_flags=extra_flags@entry=64) at t_reply.c:1051 #10 0x7f1c365cfb13 in t_should_relay_response (Trans=Trans@entry=0x7f1c2d4f9d68, new_code=new_code@entry=486, branch=branch@entry=0, should_store=should_store@entry=0x7fffdcd30a50, should_relay=should_relay@entry=0x7fffdcd30a40, cancel_data=cancel_data@entry=0x7fffdcd30c40, reply=reply@entry=0x7f1c3693b0c0) at t_reply.c:1406 #11 0x7f1c365d3196 in relay_reply (t=t@entry=0x7f1c2d4f9d68, p_msg=p_msg@entry=0x7f1c3693b0c0, branch=0, msg_status=msg_status@entry=486, cancel_data=cancel_data@entry=0x7fffdcd30c40, do_put_on_wait=do_put_on_wait@entry=1) at t_reply.c:1809 #12 0x7f1c365d7a63 in reply_received (p_msg=0x7f1c3693b0c0) at t_reply.c:2493 #13 0x004922b6 in do_forward_reply (msg=msg@entry=0x7f1c3693b0c0, mode=mode@entry=0) at forward.c:783 #14 0x00493847 in forward_reply (msg=msg@entry=0x7f1c3693b0c0) at forward.c:885 #15 0x004f5974 in receive_msg (buf=optimized out, len=optimized out, rcv_info=optimized out) at receive.c:275 #16 0x005d998d in udp_rcv_loop () at udp_server.c:521 #17 0x004a7601 in main_loop () at main.c:1629 #18 0x00425165 in main (argc=optimized out, argv=optimized out) at main.c:2561 Can be reproduced by sending a SIP INVITE containing a custom header that is empty/has no data, ex: X-model-id: . modparam(exec, setvars, 0) is currently used as a workaround. Kind regards,/Tobias Date: Mon, 29 Dec 2014 12:13:19 +0100 From: mico...@gmail.com To: sr-users@lists.sip-router.org Subject: Re: [SR-Users] Kamailio 4.2.1 crashes on using exec_msg Hello, this should be fixed in branch 4.2 -- you have to install the nightly builds (if you are using debian) or from sources branch 4.2. We will have a release very soon, as 4.2.2 which will include it -- this most probably will happen sometime next week. Cheers, Daniel On 29/12/14 12:08, Tobias wrote: Hi! We recently upgraded our Kamailio 4.1 to 4.2.1. With the newer version Kamailio crashes after just running a few minutes. After some debugging it looks as though the problem is in exec_msg (which is used in our config). After disabling this 4.2.1 seem to run just fine. Core file exists, here's the output: (gdb) backtrace #0 0x005ebf0f in fm_extract_free (frag=0x7f053ea08d18, qm=0x7f053e88e010) at mem/f_malloc.c:206 #1 fm_malloc (qm=0x7f053e88e010, size=optimized out, file=file@entry=0x7f053cbedfd4 exec: exec_hf.c, func=func@entry=0x7f053cbef378 replace_env, line=line@entry=375) at mem/f_malloc.c:490 #2 0x7f053cbe7953 in replace_env (list=0x7f053ea08868) at exec_hf.c:375 #3 0x7f053cbe862e in set_env (msg=0x7f053e91d690) at exec_hf.c:547 #4 0x7f053cbeb835 in w_exec_msg (msg=0x7f053e87c480, cmd=0x7f053ea5e168 X֤\005\177, foo=optimized out) at exec_mod.c:164 #5 0x004274f7 in do_action (h=h@entry=0x7fff02e9cf90, a=a@entry=0x7f053ea5cfb8, msg=msg@entry=0x7f053e87c480) at action.c:1094 #6 0x004261a9 in run_actions (h=h@entry=0x7fff02e9cf90, a=a@entry=0x7f053ea5cfb8, msg=msg@entry=0x7f053e87c480) at action.c:1583 #7 0x00432980 in run_top_route (a=0x7f053ea5cfb8, msg=msg@entry=0x7f053e87c480, c=c@entry=0x0) at
Re: [SR-Users] Kamailio 4.2.1 crashes on using exec_msg (also 4.2.2)
Hello, thanks for the report and details, I just pushed a fix (master, 4.2 and 4.1 branches) for properly dealing with empty headers after the patch for exec_bash_safety. Let me know if works ok. Cheers, Daniel On 13/01/15 11:56, Tobias wrote: Hi again Daniel, We've upgraded to 4.2.2 and the recent changes in exec seem to still affect our usage of exec. From new coredump on 4.2.2: (gdb) bt #0 0x7f1c34dc404b in memcpy (__len=18446744073709551614, __src=0x7f1c2d4ecc09, __dest=0x7f1c368f4be2) at /usr/include/x86_64-linux-gnu/bits/string3.h:52 #1 print_hf_var (w=optimized out, offset=optimized out) at exec_hf.c:263 #2 print_var (w=optimized out, offset=optimized out) at exec_hf.c:296 #3 create_vars (list=optimized out, offset=optimized out) at exec_hf.c:346 #4 set_env (msg=0x7f1c368f4a08) at exec_hf.c:544 #5 0x7f1c34dc6835 in w_exec_msg (msg=0x7f1c36839480, cmd=0x7f1c3692b298 , foo=optimized out) at exec_mod.c:164 #6 0x004275d7 in do_action (h=h@entry=0x7fffdcd30740, a=a@entry=0x7f1c3692a9c0, msg=msg@entry=0x7f1c36839480) at action.c:1094 #7 0x00426289 in run_actions (h=h@entry=0x7fffdcd30740, a=a@entry=0x7f1c3692a9c0, msg=msg@entry=0x7f1c36839480) at action.c:1583 #8 0x00432a90 in run_top_route (a=0x7f1c3692a9c0, msg=msg@entry=0x7f1c36839480, c=c@entry=0x0) at action.c:1669 #9 0x7f1c365cdd9a in run_failure_handlers (t=t@entry=0x7f1c2d4f9d68, rpl=0x7f1c3693b0c0, code=486, extra_flags=extra_flags@entry=64) at t_reply.c:1051 #10 0x7f1c365cfb13 in t_should_relay_response (Trans=Trans@entry=0x7f1c2d4f9d68, new_code=new_code@entry=486, branch=branch@entry=0, should_store=should_store@entry=0x7fffdcd30a50, should_relay=should_relay@entry=0x7fffdcd30a40, cancel_data=cancel_data@entry=0x7fffdcd30c40, reply=reply@entry=0x7f1c3693b0c0) at t_reply.c:1406 #11 0x7f1c365d3196 in relay_reply (t=t@entry=0x7f1c2d4f9d68, p_msg=p_msg@entry=0x7f1c3693b0c0, branch=0, msg_status=msg_status@entry=486, cancel_data=cancel_data@entry=0x7fffdcd30c40, do_put_on_wait=do_put_on_wait@entry=1) at t_reply.c:1809 #12 0x7f1c365d7a63 in reply_received (p_msg=0x7f1c3693b0c0) at t_reply.c:2493 #13 0x004922b6 in do_forward_reply (msg=msg@entry=0x7f1c3693b0c0, mode=mode@entry=0) at forward.c:783 #14 0x00493847 in forward_reply (msg=msg@entry=0x7f1c3693b0c0) at forward.c:885 #15 0x004f5974 in receive_msg (buf=optimized out, len=optimized out, rcv_info=optimized out) at receive.c:275 #16 0x005d998d in udp_rcv_loop () at udp_server.c:521 #17 0x004a7601 in main_loop () at main.c:1629 #18 0x00425165 in main (argc=optimized out, argv=optimized out) at main.c:2561 Can be reproduced by sending a SIP INVITE containing a custom header that is empty/has no data, ex: X-model-id: . modparam(exec, setvars, 0) is currently used as a workaround. Kind regards, /Tobias Date: Mon, 29 Dec 2014 12:13:19 +0100 From: mico...@gmail.com To: sr-users@lists.sip-router.org Subject: Re: [SR-Users] Kamailio 4.2.1 crashes on using exec_msg Hello, this should be fixed in branch 4.2 -- you have to install the nightly builds (if you are using debian) or from sources branch 4.2. We will have a release very soon, as 4.2.2 which will include it -- this most probably will happen sometime next week. Cheers, Daniel On 29/12/14 12:08, Tobias wrote: Hi! We recently upgraded our Kamailio 4.1 to 4.2.1. With the newer version Kamailio crashes after just running a few minutes. After some debugging it looks as though the problem is in exec_msg (which is used in our config). After disabling this 4.2.1 seem to run just fine. Core file exists, here's the output: (gdb) backtrace #0 0x005ebf0f in fm_extract_free (frag=0x7f053ea08d18, qm=0x7f053e88e010) at mem/f_malloc.c:206 #1 fm_malloc (qm=0x7f053e88e010, size=optimized out, file=file@entry=0x7f053cbedfd4 exec: exec_hf.c, func=func@entry=0x7f053cbef378 replace_env, line=line@entry=375) at mem/f_malloc.c:490 #2 0x7f053cbe7953 in replace_env (list=0x7f053ea08868) at exec_hf.c:375 #3 0x7f053cbe862e in set_env (msg=0x7f053e91d690) at exec_hf.c:547 #4 0x7f053cbeb835 in w_exec_msg (msg=0x7f053e87c480, cmd=0x7f053ea5e168 X֤\005\177, foo=optimized out) at exec_mod.c:164 #5 0x004274f7 in do_action (h=h@entry=0x7fff02e9cf90, a=a@entry=0x7f053ea5cfb8, msg=msg@entry=0x7f053e87c480) at action.c:1094 #6 0x004261a9 in run_actions (h=h@entry=0x7fff02e9cf90, a=a@entry=0x7f053ea5cfb8, msg=msg@entry=0x7f053e87c480) at action.c:1583 #7 0x00432980 in run_top_route (a=0x7f053ea5cfb8, msg=msg@entry=0x7f053e87c480, c=c@entry=0x0) at action.c:1669 #8 0x7f053e610d2a in
Re: [SR-Users] event on table location Duplicate entry for key 'ruid_idx'
Add server_id=N to kamailio.cfg on both servers, where N is an integer with unique value. userloc module will use server_id value to create unique between servers ruid. On Tuesday 13 January 2015 10:53:28 Daniel-Constantin Mierla wrote: Hello, On 12/01/15 22:54, Yuriy Gorlichenko wrote: Hello. We use 2 kamailio servers cluster and we have porblems with db. Database failed pecause of error: Could not execute Write_rows_v1 event on table production.location; Duplicate entry 'uloc-54aae947-86d-a67' for key 'ruid_idx', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's master log FIRST, end_log_pos 380, Internal MariaDB error code: 1062 But a location table no row 'ruid_idx' and no entry uloc-54aae947-86d-a67. ruid_idx is a unique key constraint on column uid. Can you check if you have that value in ruid column? Also, can you share the output of 'kamctl ps' for each of the servers? Assuming you haven't restarted the kamailios. Provide the output of 'kamailio -V' to figure out the version and the parameters for usrloc module. Cheers, Daniel ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Dispatcher 8 algorithm based on priority strange works
Daniel. I added 8 algorithm to our server and it works with 2 asterisk now
but it works strange because:
While works server with priority 1 - all ok. When this server goes down
dispatcher choose next server with lowes priority. But when server with
highest priority waking up dispatcher use server with lowes priority until
this server not goes down.
here id my config for dispatcher
modparam(dispatcher, db_url,DBURL)
modparam(dispatcher, table_name, dispatcher)
modparam(dispatcher, setid_col, setid)
modparam(dispatcher, priority_col, priority)
modparam(dispatcher, destination_col, destination)
modparam(dispatcher, force_dst, 1)
modparam(dispatcher, flags, 3)
modparam(dispatcher, dst_avp, $avp(i:271))
modparam(dispatcher, grp_avp, $avp(i:272))
modparam(dispatcher, cnt_avp, $avp(i:273))
modparam(dispatcher, ds_ping_from, sip:kamailio1@10.0.1.12)
modparam(dispatcher, ds_ping_interval,15)
modparam(dispatcher, ds_probing_mode, 1)
modparam(dispatcher, ds_ping_reply_codes,
class=2;code=403;code=404;code=484;class=3)
modparam(tm, reparse_on_dns_failover, 0)
(!ds_select_dst($var(setid), 8)){
sl_send_reply(500, Service Unavailable);
xlog(L_INFO,{$rm} from [$fU@$si:$sp] But NO destinations
available for $rd \n);
t_on_failure(DISPATCHER_ROLLOVER);
}
if (!t_relay()) {
sl_reply_error();
we use 4.3 master branch kamailio
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] pua_subscribe and force_send_socket trouble
Makes sense, I can live with this. Thanks for clarfication. -- Mikko Lehto ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
