Dears,
I'm trying drouting module in kamailio , it's working good when first
gateway in the list is up , yet when first gateway is unrecheable , it's not
rerouted to second destination, meaning that fail over is not working.
Kindly find attached wireshark trace I'm getting .
Below is db entries I'm using :
dr_gateways:
Dr_gw_lists
Dr_groups:
Dr_rules:
Below is routing block I'm using :
request_route{
if (is_method("INVITE"))
{
if (!do_routing("0")) {
send_reply("503", "Test No Rules matching
the URI");
exit;
}
route(10);
exit;
}
}
route[10] {
if (!do_routing("0")) {
xlog("do_routing: No rules matching the URI\n");
send_reply("503","No rules matching the URI");
exit;
}
if (is_method("INVITE")) {
t_on_failure("4");
}
route(1);
}
failure_route[4] {
xlog("DEBUG: DROUTING failure route active\n");
if (t_check_status("[34][0-9][0-9]")) {
exit;
}
if (use_next_gw()) {
t_relay();
exit;
} else {
t_reply ("503", "Service not available");
exit;
}
}
route[1] {
# send it out now; use stateful forwarding as it works
# reliably even for UDP2TCP
if (!t_relay()) {
sl_reply_error();
};
exit;
}
Appreciating your prompt reply and assistance.
Ali Taher
Technical Support Engineer
T&F
M
W
A
+961-5-457437 Ext 215
+961-70-010600
<http://www.vanrise.com/> http://www.vanrise.com
<https://maps.google.com/maps/ms?msa=0&msid=208243362929850217065.0004cbc8d6
12c5f9b4237&ie=UTF8&t=h&vpsrc=0&z=19&iwloc=0004cbc8e4652b4edf71cC:\Users\Mar
ie\Documents\My%20Received%20Files> Vanrise Building, Facing Galerie Semaan
Hazmiyeh Highway - Beirut, Lebanon
Join us at
<http://www.facebook.com/pages/Vanrise-Solutions-Offshore/128309743915533>
<http://www.linkedin.com/company/vanrise-solutions>
<http://twitter.com/VanriseSolution>
Hi,
we have a serious problem with Kamailio v4.2.3, it crashes after some days. We have checked the core dump and the gdb output is the following for bt and full backtrace:
#0 0x0000000000602291 in timer_list_expire (t=1432559962, h=0x7f64eb5b6bd0, slow_l=0x7f64eb5ba328, slow_mark=43873) at timer.c:877
#1 0x0000000000602746 in timer_handler () at timer.c:953
#2 0x0000000000602bb9 in timer_main () at timer.c:992
#3 0x00000000004a833c in main_loop () at main.c:1700
#4 0x00000000004ad857 in main (argc=13, argv=0x7fff96697d38) at main.c:2578
#0 0x0000000000602291 in timer_list_expire (t=1432559962, h=0x7f64eb5b6bd0, slow_l=0x7f64eb5ba328, slow_mark=43873) at timer.c:877
tl = 0x7f64ebc3a908
ret = 0
#1 0x0000000000602746 in timer_handler () at timer.c:953
saved_ticks = 1432559962
run_slow_timer = 0
i = 865
__FUNCTION__ = "timer_handler"
#2 0x0000000000602bb9 in timer_main () at timer.c:992
No locals.
#3 0x00000000004a833c in main_loop () at main.c:1700
i = 4
pid = 0
si = 0x0
si_desc = "udp receiver child=3 sock=127.0.0.1:5060\000\375\362\250/\313\345\v\004\000\000\000\000\000\000\000\004\257\263=\000\000\000\000\200TA\000\000\000\000\000\060}i\226\377\177", '\000' <repeats 19 times>, "{i\226\377\177\000\000\376\366R\000\000\000\000\000\377\377\377\377\377\177\000\000@\350\250\000\000\000\000"
nrprocs = 4
__FUNCTION__ = "main_loop"
#4 0x00000000004ad857 in main (argc=13, argv=0x7fff96697d38) at main.c:2578
cfg_stream = 0x1b94010
c = -1
r = 0
tmp = 0x7fff96699b17 ""
tmp_len = 0
port = 1
proto = 32767
options = 0x703e08 ":f:cm:M:dVIhEeb:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:"
ret = -1
seed = 2591880768
rfd = 4
debug_save = 0
debug_flag = 0
dont_fork_cnt = 0
n_lst = 0x0
p = 0x7fff96697c50 ""
__FUNCTION__ = "main"
In the logs it can be seen:
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4635]: CRITICAL: <core> [pass_fd.c:293]: receive_fd(): EOF on 21
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4612]: ALERT: <core> [main.c:784]: handle_sigs(): child process 4623 exited by a signal 11
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4612]: ALERT: <core> [main.c:787]: handle_sigs(): core was generated
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4612]: INFO: <core> [main.c:799]: handle_sigs(): terminating due to SIGCHLD
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4631]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4628]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4634]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4615]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4617]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4626]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4625]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4624]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4632]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4622]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4621]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4620]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4619]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4618]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4616]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4635]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4614]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4629]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4627]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4633]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4630]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4612]: INFO: <core> [mem/f_malloc.c:599]: fm_free(): freeing a free fragment (0x7f64eca19950/0x7f64eca19988) - ignore
Apr 23 08:07:31 ctsip1 /usr/local/sbin/kamailio[4612]: INFO: <core> [mem/f_malloc.c:599]: fm_free(): freeing a free fragment (0x7f64ed587f20/0x7f64ed587f58) - ignore
Kamailio runs on Ubuntu trusty. The interesting thing that we run Kamailio 4.2.3 in an other environment (on Debian Squeeze) and it works perfect, no crashes. The main difference is that in Debian environment we have less number of users and the firewall is not so strength. But the configuration and the source is the same for both.
Please help us to solve this problem. Thanks.
Dr. Péter Barabás
Director of Software Development
Arenim Technologies AB.
Mob: +36 70 314 56 57
Tel: +36 1 8 555 602
E-mail: peter.barabas(a)arenim.com<mailto:peter.barabas@arenim.com>
Postal: Sweden - 11435 Stockholm, Stureplan 4c, 4th. Floor
[Arenim_logo]<http://www.arenim.com/>
[CryptTalk_Logo]<http://www.crypttalk.com/>
Hi,
I'm trying to install Kamailio on a server with a public IP, but my users
are mostly at their homes (a.k.a behind NAT).
I understood I need to install RTPproxy, but all tutorials out there are
for servers behind nat, and they talk about the server's private IP, which
does not exists in this case.
how would I configure RTPproxy and Kamailio to allow users to subscribe to
the server and have audio calls between them?
MtK
Hi all,
Im wondering if anyone can share their schema files for dbcassandra.
Ive managed to construct a bunch based on what ive found in git, wiki all
over the place,
I just want to compare my ones, with some others.
specifically the location table.
--
Sincerely
Jay
Hello,
as branch 4.3 was created to host the upcoming release series 4.3, new
features can be now pushed to master branch. They will be part of the
next future release, likely to be numbered 4.4.
Any fixes that affect existing code in branches 4.3 or older version
have to be backported - push first to master and then cherry pick --
some guidelines exemplified with branch 3.2 are available at:
- https://www.kamailio.org/wiki/devel/backporting-to-3.2.x
As usual, the next future release will be out as stable version in like
8-10 months.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, May 27-29, 2015
Berlin, Germany - http://www.kamailioworld.com
Hello,
the GIT branch 4.3 was created, it will host the release series 4.3.x.
To get this branch from GIT, you can use:
git clone https://github.com/kamailio/kamailio.git kamailio
cd kamailio
git checkout -b 4.3 origin/4.3
Notes about installing Kamailio from this branch are available at:
- http://www.kamailio.org/wiki/install/4.3.x/git
Hopefully in about two weeks or so the full release of 4.3.0 will be out.
>From now on, any corresponding fix has to be pushed first to master
branch and then cherry-picked to branch 4.3. No new features can get in
branch 4.3. Enhancements to documentation or helping tools are still
allowed.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, May 27-29, 2015
Berlin, Germany - http://www.kamailioworld.com
Hey Guys,
Was wondering what would be the recommended way to share information
between $evapi(msg) received and transaction processors?
I have tried $avp() but they do not appear to be available in
evapi:message-received route. Trying to avoid here $sht() so I don't
need to do extra management to destroy them. Is there any way to
"activate" the $avp or $dlg_var based on dialog index, label maybe?
Thanks in advance for any kind of tip!
DanB
//
Hello,
I am planning to branch the code for upcoming major release on next
Monday, May 25. Testing went fine so far in my side and I don't expect
new consistent changes. Any fixes afterwards will be backported as usual
to a stable branch. From that moment, master branch will be open again
for new features.
If someone else has different proposal, let's discuss it on sr-dev
mailing list.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, May 27-29, 2015
Berlin, Germany - http://www.kamailioworld.com
Hi Austin,
Kamailio will not reject by himself (nor handle) PRACK (or any other
methods) unless you tell him so. The logic for handling it should be in
your .cfg file.
I suggest adding xlog statements through your config script and see
where that is rejected. 404 would tell me you are trying to locate your
endpoint and send the PRACK there but the endpoint is not registered.
DanB
