Hi all,
I'm switching my development environment from Linux to Mac.
Is there any tutorial on how to setup Kamailio on this OS? It may be an
Unix flavor, but it's still quite different from Linux :).
Thanks,
--
Carlos
http://caruizdiaz.comhttp://ngvoice.com
+52 55 3048 3303
Hello,
I’m attempting to deploy a homer sip capture server on SPARC and I’m seeing some strange date related errors:
ERROR: db_mysql [km_dbase.c:128]: db_mysql_submit_query(): driver error on query: Incorrect datetime value: '2052-06-12 16:21:06' for column 'date' at row 1 (1292)
Is there some sore of endianness issue?
Thanks for any assistance!
Regards,
Spencer
Hi fellow kamailio users,
I'm playing actually with t_on_branch_failure, in a simultaneous forking
scenario ( lookup("location") returns multiple contacts ).
Any idea on how to get those "on_branch_failure" working ?
Thanks in Advance !
* Test by putting failure_exec_mode:
- at 1 => no branch failure being called, never.
- at 0 => t_relay does not fail if a single branch answers the
transaction, even if all other branches are failing.
* Test by moving the t_on_branch_failure("manage_branch_failure"); line
before or after the lookup("location") or on a _on_branch route to set
it per branch.
- The on_route branch are executed, but never the failure one.
- tried also with failure_exec_mode = 0 or 1.
* Using set_forward_no_connect, I can see in the logs a "Sending to
branch X failed" but no failure route being executed. Without it,
nothing in the logs indicating that the branch has timeout.
* Config extract:
# auto-discard branches from previous serial forking leg
modparam("tm", "failure_reply_mode", 3) # 3 by default
# default retransmission timeout: 30sec
modparam("tm", "fr_timer", 30000)
# default invite retransmission timeout after 1xx: 120sec
modparam("tm", "fr_inv_timer", 120000)
modparam("tm", "reparse_on_dns_failover", 0)
# 1: Allow branches to have a per branch failure route
# 0: t_relay should fail if a branch fail
modparam("tm", "failure_exec_mode", 1)
# Allow locally generated 408 to be forgotten in case a reply is received.
#modparam("tm", "faked_reply_prio", 2000)
# USER location service
route[LOCATION] {
t_on_branch_failure("manage_branch_failure");
if (!lookup("location")) {
....
}
# Let's get back after 2.5s if no 100/Trying received.
t_set_fr(0, 2500);
# set_forward_no_connect();
#t_on_branch("SET_BRANCH_FAILURE");
route(RELAY);
exit;
}
route[RELAY] {
....
if (!t_relay()) {
xlog("L_WARN","$rm|$ci|$fu|$tu|RELAY_FAILED");
sl_reply_error();
}
exit();
}
# set failure route per branch
branch_route[SET_BRANCH_FAILURE] {
xlog("L_WARN","$rm|$ci|$fu|$tu|SETTING_BrANCH_FAILURE_ROUTE");
t_on_branch_failure("manage_branch_failure");
}
# manage failure routing cases per branch
event_route[tm:branch-failure:manage_branch_failure] {
xlog("L_WARN","$rm|$ci|$fu|$tu[$avp(dest_to)]|MANAGE_BRANCH_FAILURE");
}
Happy New Year!
I've just upgraded my Kamailio (build from master@c7e411e) instance to Fedora
23 from Fedora 22. I've built the packages specifically for Fedora 23 with
the following current sources:
openssl-1.0.2e-3.fc23.x86_64
openssl-libs-1.0.2e-3.fc23.x86_64
openssl version reports...
OpenSSL 1.0.2e-fips 3 Dec 2015
Even so, the following error occurs. It seems like Kamailio having trouble
detecting that I'm using running with the same version that I have installed,
and the same version that I have compiled against.
tls [tls_init.c:557]: init_tls_h(): ERROR: tls: init_tls_h: installed openssl
library version is too different from the library the Kamailio tls module was
compiled with: installed "OpenSSL 1.0.0-fips 29 Mar 2010" (0x10000003),
compiled "OpenSSL 1.0.2d-fips 9 Jul 2015" (0x1000204f).
Please make sure a
compatible version is used (tls_force_run in kamailio.cfg will override this
check)
CRITICAL: <core> [main.c:2558]: main(): could not initialize tls, exiting...
Any pointers? -A
--
Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery
8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E
Hello All,
I have a need to save the Record-Route header from the INVITE and
use it as a route header in requests like BYE.
PROXY --> Kamailio(as PROXY) --> Asterisk
I am using rr module to add a record_route when passing the INVITE to Asterisk.
Thanks,
Jignesh Gandhi
Hi,
we have a load balancer which is handling a lot of SIP traffic all day.
There's always 20-40 Mbit SIP traffic going through. From time to time we
see in our logs messages like these:
Sep 16 09:46:28 ecker /usr/sbin/kamailio[25505]: ERROR: <core>
[udp_server.c:591]: udp_send(): ERROR: udp_send:
sendto(sock,0x7f2d9d6b3ce0,1321,0,46.237.225.126:5060,16): Operation not
permitted(1)
Sep 16 09:46:38 ecker /usr/sbin/kamailio[25194]: ERROR: <core>
[udp_server.c:591]: udp_send(): ERROR: udp_send:
sendto(sock,0x7efc982b8fc8,420,0,82.113.121.183:35794,16): Operation not
permitted(1)
Sep 16 09:46:40 ecker /usr/sbin/kamailio[25505]: ERROR: <core>
[udp_server.c:591]: udp_send(): ERROR: udp_send:
sendto(sock,0x7f2d9d6b3ce0,1338,0,5.158.137.9:55067,16): Operation not
permitted(1)
Sep 16 09:46:44 ecker /usr/sbin/kamailio[25183]: ERROR: <core>
[udp_server.c:591]: udp_send(): ERROR: udp_send:
sendto(sock,0x7efc982d9f48,450,0,178.165.131.197:37515,16): Operation not
permitted(1)
Sep 16 09:46:49 ecker /usr/sbin/kamailio[25643]: ERROR: <core>
[udp_server.c:591]: udp_send(): ERROR: udp_send:
sendto(sock,0x7f93fb624530,496,0,172.56.7.69:25643,16): Operation not
permitted(1)
Sep 16 09:46:55 ecker /usr/sbin/kamailio[25335]: ERROR: <core>
[udp_server.c:591]: udp_send(): ERROR: udp_send:
sendto(sock,0x7f41632cda98,598,0,80.215.234.139:3396,16): Operation not
permitted(1)
Sep 16 09:46:56 ecker /usr/sbin/kamailio[25345]: ERROR: <core>
[udp_server.c:591]: udp_send(): ERROR: udp_send:
sendto(sock,0x7f41632f4840,459,0,94.197.120.191:8225,16): Operation not
permitted(1)
I know that these messages can be produced by iptables blocking the
outbound traffic. But our outbound chain looks basically like this:
root@ecker:~# iptables-save | grep OUTPUT
:OUTPUT DROP [0:0]
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-j ACCEPT
-A OUTPUT -m state --state INVALID -j DROP
-A OUTPUT -o lo -m state --state NEW -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -m state --state NEW -j ACCEPT
We don't have the nf_ct_sip module loaded, syslog doesn't say anything, and
even clearing all iptables rules doesn't eliminate those errors.
Has anyone ever seen this? It looks like a load thing, because at weekends
there are significantly less errors.
Thanks,
Sebastian
Hi folk!
Have a rare issue with tls connections.
Have a server with 100+ active tls connections, that are connected to
separate TCP proxy, that listen on port 443.
TCP proxy send sip traffic to Kamailio via localhost:5061. In this way all
connections in Kamailio are considered from Localhost.
Issue scheme:
- UA-A (sip-phone, UDP/TCP/TLS) -> call -> sip server (Kamailio+Asterisk
based) -> UA-B (sip phone, transport=TLS)
- The troubles happened in part of flow to UA-B:
--- kamailio script make lookup(location), find AOR for UA-B (here is OK)
--- after t_relay, kamailio make branch_route logic and try to send INVITE
to tcp socket
--- HERE IS the trouble: connection seems to be opened, but Kamailio cannot
send INVITE there (say: no open tcp connection found)
--- Kamailio try to open tcp connection from itself, TCP proxy refuse it
--- as a result - Kamailio answer 477 to Asterisk, and finish processing
debug level 3 logs (from the point where Kamailio try to send INVITE in
opened connection)
Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: <core> [tcp_main.c:1463]:
_tcpconn_find(): tcpconn_find: 0 port 60286
Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: <core> [ip_addr.c:243]:
print_ip(): tcpconn_find: ip 127.0.0.1
Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: <core> [tcp_main.c:1820]:
tcp_send(): tcp_send: no open tcp connection found, opening new one
Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: <core> [ip_addr.c:243]:
print_ip(): tcpconn_new: new tcp connection: 127.0.0.1
Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: <core> [tcp_main.c:1073]:
tcpconn_new(): tcpconn_new: on port 60286, type 3
Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: <core> [tcp_main.c:1626]:
_tcpconn_add_alias_unsafe(): _tcpconn_add_alias_unsafe: alias port 60286 for
hash 2646, id 404319
Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: <core> [tcp_main.c:1626]:
_tcpconn_add_alias_unsafe(): _tcpconn_add_alias_unsafe: alias port 60286 for
hash 2728, id 404319
Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: <core> [tcp_main.c:1624]:
_tcpconn_add_alias_unsafe(): _tcpconn_add_alias_unsafe: alias already
present
Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: <core> [tcp_main.c:1382]:
tcpconn_add(): tcpconn_add: hashes: 2646:2728:0, 863
Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: tls [tls_server.c:184]:
tls_complete_init(): Using TLS domain TLSc<default>
Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: tls [tls_domain.c:700]:
sr_ssl_ctx_info_callback(): SSL handshake started
Jan 25 14:32:43 /usr/sbin/kamailio[4722]: ERROR: <core> [tcp_main.c:2742]:
tcpconn_1st_send(): connect 127.0.0.1:60286 failed (RST) Connection refused
Jan 25 14:32:43 /usr/sbin/kamailio[4722]: ERROR: <core> [tcp_main.c:2752]:
tcpconn_1st_send(): 127.0.0.1:60286: connect & send for 0xb1d3b7e8 failed:
Connection refused (111)
Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: <core> [tcp_main.c:2947]:
tcpconn_chld_put(): tcpconn_chld_put: destroying connection 0xb1d3b7e8
(404319, -1) flags 0060
Jan 25 14:32:43 /usr/sbin/kamailio[4722]: ERROR: tm [../../forward.h:247]:
msg_send(): tcp_send failed
Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: tm [t_fwd.c:1591]:
t_send_branch(): t_send_branch: send to 127.0.0.1:60286 (3) failed
Jan 25 14:32:43 /usr/sbin/kamailio[4722]: WARNING: tm [t_fwd.c:1610]:
t_send_branch(): ERROR: t_send_branch: sending request on branch 0 failed
Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: tm [t_funcs.c:358]:
t_relay_to(): ERROR:tm:t_relay_to: t_forward_nonack returned error
Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: tm [t_funcs.c:375]:
t_relay_to(): -477 error reply generation delayed
Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: tm [t_lookup.c:1526]:
t_unref(): t_unref: delayed error reply generation(-477)
Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: <core>
[parser/msg_parser.c:339]: parse_headers(): parse_headers:
flags=ffffffffffffffff
Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: tm [t_reply.c:1670]:
cleanup_uac_timers(): DEBUG: cleanup_uac_timers: RETR/FR timers reset
Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: tm [t_reply.c:728]:
_reply_light(): DEBUG: reply sent out. buf=0xb67c000c: SIP/2.0 477
Unfortun..., shmem=0xb1b676cc: SIP/2.0 477 Unfortun
Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: tm [t_funcs.c:156]:
put_on_wait(): DEBUG: put on WAIT
Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: tm [t_reply.c:738]:
_reply_light(): DEBUG: _reply_light: finished
Additionally want to say, that suddenly we don't have clear reproduce, it
happened only on 2 production servers, what are common conditions for issue:
- transport=TLS
- when issued call is done, I checked with netstat, the connection is alive
- the issued device is re-REGISTERed as usual, in kamctl ul show I see
registration before/during/after issued call
- issue appear only when connection through our custom TCP proxy :443 (to
Kamailio it is from 127.0.0.1:5061)
- if connection switched to Kamailio 5061 directly - issue never (till now)
reproduced
- in one of the issued server - I noticed big number of tcp id. Doing kamcmd
core.tcp_list, I saw e.g. id: 567852 (usually id numbers are not more than
1000).
- if kamailio/device reboot - problem disappear
Because of not completely understanding how tcp core is working in kamailio,
ask any suggestion, why such could happen.
Any idea/hints would be greatly appreciated!
kamailio -v
version: kamailio 4.2.5 (i386/linux)
flags: STATS: Off, EXTRA_DEBUG, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
F_MALLOC, DBG_F_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: unknown
compiled on 16:03:38 Jan 12 2016 with gcc 4.3.2
sorry for the long description
cheers!
--
View this message in context: http://sip-router.1086192.n5.nabble.com/rare-impossibility-to-send-requests…
Sent from the Users mailing list archive at Nabble.com.
Hi all,
A different BLF query to my other one so creating another thread.
We've tried to have a BLF client SUBSCRIBE using a secondary IP on Kamailio. It is not sent a NOTIFY, but a client which has done a SUBSCRIBE using the primary IP is. If we route the problematic client such that it connects to the primary IP, it too is sent a NOTIFY.
Looking at the query that is done on the database when a call is made to 441164969988 it is as follows:
select `callid`,`to_tag`,`from_tag` from `active_watchers` where `presentity_uri`='sip:441164969988@185.28.212.118' AND `event`='dialog'
Where 185.28.212.118 is the primary IP. In reality, it should be doing an additional query for anything considered `myself`. i.e.
select `callid`,`to_tag`,`from_tag` from `active_watchers` where `presentity_uri`='sip:441164969988@10.20.11.118' AND `event`='dialog'
I've been scouring the docs for a way to add additional IPs and/or domains for the purpose of querying active_watchers but I can't see anything relevant.
What's the process here?
Thanks
Phil
Im trying to enable Kamailio TLS but the configuration is not running at
all when I cahnge it liike this as follow.
Kamailio 3.3 ubuntu 12.04 LTS
#!define WITH_TLS
#!ifdef WITH_TLS
enable_tls=yes
#!endif
#!ifdef WITH_TLS
loadmodule "tls.so"
#!endif
#!ifdef WITH_TLS
# ----- tls params -----
modparam("tls", "config", "/etc/kamailio/tls.cfg")
#!endif
Please help
--
Kethzer Docteur
