Hello,
can you grab and send the backtrace with gdb from corefile? The logs
show that core was generated. While I don't use dmq that much, maybe it
is something easy to fix.
Cheers,
Daniel
On 18.10.17 22:58, : Paolo Visintin - Time-Net S.r.l. wrote:
Hi Daniel,
I have gone in deep and made more tests, the behaviour is this:
kamailio.01 and kamailio.02 shares the same dialog database, for sync
purpose.
If call is handled by kamailio.01 I can see dialogs only in
kamailio.01 (kamcmd dlg.list)
If call is handled by kamailio.01 and, in the meantime, I restart
kamailio.02 I can see dialogs in both!
So I suppose that there's a sync memory > DB and not a bi-directional
sync. Only at startup kamailio fetch existing dialogs and store them
in memory, right ?
I tried another approach now, enabled DMQ sync with:
modparam("dialog", "enable_dmq", 1)
with separate port dedicated for DMQ messages
Dialogs are synced, but when a call is hangupped kamailio crashes!
4(1570) INFO: tmx [t_var.c:527]: pv_get_tm_reply_code(): unsupported
route_type 64 - code set to 0
22(1588) CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 15
0(1549) ALERT: <core> [main.c:742]: handle_sigs(): child process 1570
exited by a signal 11
0(1549) ALERT: <core> [main.c:745]: handle_sigs(): core was generated
0(1549) INFO: <core> [main.c:768]: handle_sigs(): terminating due to
SIGCHLD
5(1571) INFO: <core> [main.c:823]: sig_usr(): signal 15 received
...
1(1567) INFO: <core> [main.c:823]: sig_usr(): signal 15 received
0(1549) CRITICAL: <core> [main.c:649]: sig_alarm_abort(): shutdown
timeout triggered, dying
My purpose is to share dialogs and usrloc data between kamailio
instances (10 about) in order to manage shared dialogs.
Cheers,
Paolo
2017-10-18 18:06 GMT+02:00 Daniel-Constantin Mierla <miconda(a)gmail.com
<mailto:miconda@gmail.com>>:
Hello,
On 17.10.17 10:27, : Paolo Visintin - Time-Net S.r.l. wrote:
Hi kamailio users, I'm wondering if
there's something already
done with shared dialog among more kamailio instances, in order
to manage branches initalized by another kamailio instance.
A
ctually seems not possible (also with db mode) because kamailio
is looking into caller/callee_sock and if it's different does not
manage
in a "standard" failover environment (master / slave) with vIP
and keepalived and $fs = VIRTUAL_IP everything is working fine
but in a distributed environment this could not happen as the
relay is managed by a kamailio proxy
I looked at the code and the dialog module just not sets the local
socket fields if there is no match, but loads them from db and all
should be fine, an existing socket will be used if there is a need
to send BYE. What exactly you encointered? There is a warning
message when the local socket is not matched, but it's about
ignoring the socket field, not ignoring the dialog from db.
Cheers,
Daniel
--
Daniel-Constantin Mierla
www.twitter.com/miconda <http://www.twitter.com/miconda> --
www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
Kamailio Advanced Training, Nov 13-15, 2017, in Berlin -
www.asipto.com
<http://www.asipto.com>
Kamailio World Conference -
www.kamailioworld.com
<http://www.kamailioworld.com>