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
Im trying to remove my Asterisk s= line on SDP but when doing:
sdp_remove_line_by_prefix("s=Asterisk");
Nothing happens.
Loaded sdpops.so module as well.
Is there any additional needed?
BR
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 everyone i am installing Kamailio to scale asterisk on a remote hosted server in a way to manage calls dialogs in a real-time fashion. (and to manage many customers)
Several users (maybe 80) are working at the head-office and i want them register their hardphone on the remote Kamailio Ipbx, to free them of ours end-of-life PABX (alcatel-Lucent).
Can kamailio help me to achieve that ?
What kind of software have I to install locally (mysql to replicate the master mysql db? a replicated asterisk instance?) ? Taking into consideration disaster recovery plan What could be my options to maintain internal call if my internet provider get down by exemple.
thx you for your idea.
Sébastien BRICE VoIP, Support et Intégration
Hi Cristina,
> But I have another problem related to registration process. After REGISTER-
> 401 Unauthorized-REGISTER-200 OK, the IMS client sends the SUBSCRIBE
> message (for the "reg" event package subscription) to the S-CSCF, the latter
> replies with NOTIFY and the client correctly responds with 200 OK. In order to
> be notified on any change of registration state for the client, also the P-CSCF
> sends the SUBSCRIBE message to the S-CSCF, the S-CSCF sends a NOTIFY to
> the proxy but, instead of replying with 200 OK, the P-CSCF replies with 404-
> Not Here (like it doesn't recognize that the recipient of the NOTIFY in the
> Req-URI is the P-CSCF itself).
>
> Have you ever seen similar issue?
I have now spent some time to reproduce the issue.
First of all: I had to adapt module reg_mod.c in ims_registrar_pcscf, because it containes a hardcoded P-CSCF address:
str pcscf_uri = str_init("sip:pcscf.ims.smilecoms.com:4060");
which is only valid for smilecoms.
Did you also change that?
Then I got exactly the same problem. I found that the P-CSCF config causes in the part "# Check for Subsequent requests:" a reject " sl_send_reply("404","Not here");"
I have doubts that this is correctly designed and have to dig deeper into the logic of the config-file.
Fact is: the NOTIFY request does not contain a Route header and as it not an ACK it goes straight to the reject.
Maybe any IMS expert can shed some light on this code as shown below:
# Check for Subsequent requests:
if (has_totag()) {
# sequential request withing a dialog should
# take the path determined by record-routing
if (loose_route()) {
if ($route_uri =~ "sip:mo@.*") {
setflag(FLT_MO);
}
if(!isdsturiset()) {
handle_ruri_alias();
}
# RTP-Relay, if necessary
route(RTPPROXY);
t_relay();
} else {
if ( is_method("ACK") ) {
if ( t_check_trans() ) {
# no loose-route, but stateful ACK;
# must be an ACK after a 487
# or e.g. 404 from upstream server
t_relay();
exit;
} else {
# ACK without matching transaction ... ignore and discard
exit;
}
}
sl_send_reply("404","Not here");
}
exit;
BR Franz
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.
