Hi,
I started using db_cluster module.
DB are master-slave replication both ways.
#!define DBURL "cluster://kamailio"
when i stop the primary mysql server, all subscribers fails to register
again.
seems like the usrloc module does not work with the cluster.
modparam("usrloc", "db_mode", 1)
modparam("db_cluster", "cluster", "kamailio=>primary=9s9s;secondary=8s8s")
it works OK for modules like dispatcher and htable to reload from DB.
it shows the sql driver errors, but reloads from the secondary server.
I need auto expire, so, p_usrloc is not a good option.
working with version 4.2
any ideas ?
Uri
Hello,
I'm trying to replace two old Audiocodes gateways (used to interconnect our Skype for Business infrastructure to the PSTN) with a new Kamailio cluster.
I am having some trouble to get the TLS mutual authentication working with Kamailio. For the moment, I'm just trying to receive the incoming OPTIONS from SfB, but I get all the time certificate verification errors:
ERROR: tls [tls_util.h:42]: tls_err_ret(): TLS accept:error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed
ERROR: <core> [tcp_read.c:1330]: tcp_read_req(): ERROR: tcp_read_req: error reading
My tls.cfg is quite simple, with the same config for client and server (and one single listen=tls:<my IP>:5061 in the Kamailio.cfg file)
[server:default]
method = TLSv1+
verify_certificate = yes
require_certificate = yes
private_key = /usr/local/etc/kamailio/tls/key_gw_sfb.pem
certificate = /usr/local/etc/kamailio/tls/cert_gw_sfb.pem # => This certificate's Subject is the DNS alias for the cluster, with all the kamailios in the cluster as Subject Alternative Names
ca_list = /usr/local/etc/kamailio/tls/myca_and_sfbca.pem # => Kamailio and Skype for Business are signed by different CAs, so here I concatenated all intermediate and root CAs
[client:default]
method = TLSv1+
verify_certificate = yes
require_certificate = yes
private_key = /usr/local/etc/kamailio/tls/key_gw_sfb.pem
certificate = /usr/local/etc/kamailio/tls/cert_gw_sfb.pem
ca_list = /usr/local/etc/kamailio/tls/myca_and_sfbca.pem
When I run Kamailio, I can see incoming OPTIONS from Microsoft Exchange Unified Messaging (UM), whose certificate I verify without any issues. UM presents a certificate issued for a single machine, so no Subject Alternative Names (SANs) are involved.
The problem comes with the TLS handshake for the Skype Mediation pool. They have a certificate with Subject = DNS alias and all the physical machines that are behind the alias appear listed as Subject Alternative Names (SANs) in the certificate.
As the only difference between UM and Skype's Mediation is the certificate's Subject, I think I am missing something on my configuration to validate the SANs instead of the subject. Is the TLS module doing any reverse DNS lookup to verify this?
Thanks,
Francisco.
Hello there,
I'm writing here in order to get your experiences about a Presence & IM
server.
I would like to know what is the best solution to follow:
- SIP Simple or XMPP?
I've more knowledge about SIP Simple with kamailio but i did some
researches and i found several open sources unified communications software
that's implement Presence and IM using an XMPP server.
So what is your opinion about which is the best solution to choose, taking
in considerations the following aspects:
1. scalability
2. interopeability
3. permornace
4. features(like: Personal assistance, voicemail integration, chat
group, integration with social media)
Should i choose Kamailio SIP Simple with xcap or an XMPP server(Prosody or
ejabberd, etc)
I will appreciate a lot your opinion.
Thank you
Regards
José
--
Cumprimentos
José Seabra
Hi All,
I have a strange issue, I have set the module parameter for nathelper's
force_socket to a specfic ip/port, however, when I perform a sip trace I
can see that all locally generated options messages are not sent from
the socket defined in the modules parameters.
I am not setting $fs anywhere in the script, so I am not over-writing
it. Do any of the other module parameters have a bearing on if nathelper
uses the force_socket parameter?
My current nathelper settings are:
modparam("nathelper", "received_avp", "$avp(RECEIVED)")
modparam("nathelper", "natping_interval", 20)
modparam("nathelper", "natping_processes", 4)
modparam("nathelper", "ping_nated_only", 1)
modparam("nathelper", "sipping_from", "sip:keepalive@domain.com")
modparam("nathelper", "sipping_method", "OPTIONS")
modparam("nathelper", "sipping_bflag", NAT_BFLAG)
modparam("nathelper", "force_socket", "1.2.3.4:5060")
I am using kamailio v4.3.1:
# kamailio -V
version: kamailio 4.3.1 (x86_64/linux) f38e67
flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, 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: f38e67
compiled on 18:15:23 Jul 20 2015 with gcc 4.4.7
Thanks
Hello !
I have multi crashes on a Kamailio 4.2.8 instance.
Already 6 coredump today, same time with the same scenario. Below the output
of the last coredump:
(gdb) where
#0 0x0000003d6f6328a5 in raise () from /lib64/libc.so.6
#1 0x0000003d6f634085 in abort () from /lib64/libc.so.6
#2 0x000000000061aad2 in qm_debug_frag (qm=0x7f9a8a7aa010,
f=0x7f9a8aca5968) at mem/q_malloc.c:161
#3 0x000000000061bf1c in qm_malloc (qm=0x7f9a8a7aa010, size=24,
file=0x7131d0 "<core>: re.c", func=0x71483e "subst_run", line=440) at
mem/q_malloc.c:388
#4 0x0000000000505e2c in subst_run (se=0x7f9a8ac08b78, input=0x7f9a8aca5918
"sip:0123456789@customer.local", msg=0x7f9a8abfef38, count=0x0) at re.c:440
#5 0x0000000000506fff in subst_str (input=0x7f9a8aca5918
"sip:0123456789@customer.local", msg=0x7f9a8abfef38, se=0x7f9a8ac08b78,
count=0x0) at re.c:515
#6 0x00007f9a87ff629d in subst_uri_f (msg=0x7f9a8abfef38,
subst=0x7f9a8ac08b78 "X\215\300\212\232\177", ignored=0x0) at textops.c:744
#7 0x000000000041d51b in do_action (h=0x7fffed0800d0, a=0x7f9a8ab64cc8,
msg=0x7f9a8abfef38) at action.c:1094
#8 0x0000000000429ba3 in run_actions (h=0x7fffed0800d0, a=0x7f9a8ab64cc8,
msg=0x7f9a8abfef38) at action.c:1583
#9 0x000000000042a208 in run_actions_safe (h=0x7fffed081380,
a=0x7f9a8ab64cc8, msg=0x7f9a8abfef38) at action.c:1648
#10 0x0000000000542994 in rval_get_int (h=0x7fffed081380,
msg=0x7f9a8abfef38, i=0x7fffed080890, rv=0x7f9a8ab64ef8, cache=0x0) at
rvalue.c:924
#11 0x0000000000546bcc in rval_expr_eval_int (h=0x7fffed081380,
msg=0x7f9a8abfef38, res=0x7fffed080890, rve=0x7f9a8ab64ef0) at rvalue.c:1918
#12 0x000000000041cf77 in do_action (h=0x7fffed081380, a=0x7f9a8ab66a30,
msg=0x7f9a8abfef38) at action.c:1064
#13 0x0000000000429ba3 in run_actions (h=0x7fffed081380, a=0x7f9a8ab66a30,
msg=0x7f9a8abfef38) at action.c:1583
#14 0x000000000041d3f6 in do_action (h=0x7fffed081380, a=0x7f9a8ab6b070,
msg=0x7f9a8abfef38) at action.c:1079
#15 0x0000000000429ba3 in run_actions (h=0x7fffed081380, a=0x7f9a8ab607b8,
msg=0x7f9a8abfef38) at action.c:1583
#16 0x000000000042a2d0 in run_top_route (a=0x7f9a8ab607b8,
msg=0x7f9a8abfef38, c=0x7fffed081380) at action.c:1669
#17 0x00007f9a891f6d0f in prepare_new_uac (t=0x7f9a6de86518,
i_req=0x7f9a8abfef38, branch=0, uri=0x7fffed0814d0, path=0x7fffed0814b0,
next_hop=0x7f9a8abff1a8, fsocket=0x0,
snd_flags=..., fproto=0, flags=2, instance=0x7fffed0814a0,
ruid=0x7fffed081490, location_ua=0x7fffed081480) at t_fwd.c:410
#18 0x00007f9a891faded in add_uac (t=0x7f9a6de86518, request=0x7f9a8abfef38,
uri=0x7f9a8abff1a8, next_hop=0x7f9a8abff1a8, path=0x7f9a8abff568, proxy=0x0,
fsocket=0x0,
snd_flags=..., proto=0, flags=2, instance=0x7f9a8abff578,
ruid=0x7f9a8abff590, location_ua=0x7f9a8abff5a0) at t_fwd.c:855
#19 0x00007f9a89201ddd in t_forward_nonack (t=0x7f9a6de86518,
p_msg=0x7f9a8abfef38, proxy=0x0, proto=0) at t_fwd.c:1723
#20 0x00007f9a891ee374 in t_relay_to (p_msg=0x7f9a8abfef38, proxy=0x0,
proto=0, replicate=0) at t_funcs.c:355
#21 0x00007f9a8922bd89 in _w_t_relay_to (p_msg=0x7f9a8abfef38, proxy=0x0,
force_proto=0) at tm.c:1517
#22 0x00007f9a8922ceee in w_t_relay (p_msg=0x7f9a8abfef38, _foo=0x0,
_bar=0x0) at tm.c:1718
#23 0x000000000041d48d in do_action (h=0x7fffed082190, a=0x7f9a8a83e878,
msg=0x7f9a8abfef38) at action.c:1088
#24 0x0000000000429ba3 in run_actions (h=0x7fffed082190, a=0x7f9a8a83e878,
msg=0x7f9a8abfef38) at action.c:1583
#25 0x000000000042a208 in run_actions_safe (h=0x7fffed0848f0,
a=0x7f9a8a83e878, msg=0x7f9a8abfef38) at action.c:1648
#26 0x0000000000542994 in rval_get_int (h=0x7fffed0848f0,
msg=0x7f9a8abfef38, i=0x7fffed082668, rv=0x7f9a8a83eb60, cache=0x0) at
rvalue.c:924
#27 0x0000000000546bcc in rval_expr_eval_int (h=0x7fffed0848f0,
msg=0x7f9a8abfef38, res=0x7fffed082668, rve=0x7f9a8a83eb58) at rvalue.c:1918
#28 0x0000000000546fc2 in rval_expr_eval_int (h=0x7fffed0848f0,
msg=0x7f9a8abfef38, res=0x7fffed082af0, rve=0x7f9a8a83f280) at rvalue.c:1926
#29 0x000000000041cf77 in do_action (h=0x7fffed0848f0, a=0x7f9a8a83fbd0,
msg=0x7f9a8abfef38) at action.c:1064
#30 0x0000000000429ba3 in run_actions (h=0x7fffed0848f0, a=0x7f9a8a838c88,
msg=0x7f9a8abfef38) at action.c:1583
#31 0x0000000000419f13 in do_action (h=0x7fffed0848f0, a=0x7f9a8a996598,
msg=0x7f9a8abfef38) at action.c:712
#32 0x0000000000429ba3 in run_actions (h=0x7fffed0848f0, a=0x7f9a8a9955b8,
msg=0x7f9a8abfef38) at action.c:1583
#33 0x000000000041d3f6 in do_action (h=0x7fffed0848f0, a=0x7f9a8a996a50,
msg=0x7f9a8abfef38) at action.c:1079
#34 0x0000000000429ba3 in run_actions (h=0x7fffed0848f0, a=0x7f9a8a8fa068,
msg=0x7f9a8abfef38) at action.c:1583
#35 0x0000000000419f13 in do_action (h=0x7fffed0848f0, a=0x7f9a8a830c70,
msg=0x7f9a8abfef38) at action.c:712
#36 0x0000000000429ba3 in run_actions (h=0x7fffed0848f0, a=0x7f9a8a830c70,
msg=0x7f9a8abfef38) at action.c:1583
#37 0x000000000041d3f6 in do_action (h=0x7fffed0848f0, a=0x7f9a8a830db8,
msg=0x7f9a8abfef38) at action.c:1079
#38 0x0000000000429ba3 in run_actions (h=0x7fffed0848f0, a=0x7f9a8a81e7d0,
msg=0x7f9a8abfef38) at action.c:1583
#39 0x000000000042a2d0 in run_top_route (a=0x7f9a8a81e7d0,
msg=0x7f9a8abfef38, c=0x0) at action.c:1669
#40 0x00000000005095b6 in receive_msg (
buf=0xa78b60 "INVITE
sip:0123456789@A.B.C.181:5060;transport=UDP;user=phone SIP/2.0\r\nFrom:
<sip:0987654321@A.B.C.148:5060>;tag=BN1507883839-1-1507047459-332794206;tran
sport=UDP\r\nTo: <sip:0123456789@H.G.F.D"..., len=1119,
rcv_info=0x7fffed084be0) at receive.c:216
#41 0x000000000060945a in udp_rcv_loop () at udp_server.c:521
#42 0x00000000004a6e62 in main_loop () at main.c:1629
#43 0x00000000004acfa6 in main (argc=7, argv=0x7fffed085018) at main.c:2581
Regards,
Igor.
Hi use 5.0.1 with presence
for TCP/UDP endpoints presence works PERFECT
but for WS socket presence i see next (small cleaned log here with all
described bellow https://pastebin.com/8a77ggj0 ):
When WS endpoint subscribes - kamailio After kamailio sends 202 to
SUBSCRIBE message (see it on client) it sends fast NOTIFY correcly without
any trouble, and i see at the kamailio reply from WS endpoint - 200
WS endpoint added to active_watchers table.
But when Subscribed endpoint makes for example some call and presence
server sends PUBLISH i see:
presence [presentity.c:426]: delete_presentity_if_dialog_id_exists():
Presentity already exists - deleting it
At the logs and then presence server doesn't send NOTIFY to WS endpoint
What is the issue of this? Can not understand why it happens. Can someone
to help me understand this?
And the dump i see that kamailio send first NOTIFY form UDP port but then
translates it to tls for websocket and i see correct NOTIFY at the WS
endpoint
