Hello,
Are you still experiencing the issue? If so, are you able to provide a
backtrace?
Cheers,
Charles
On 23 October 2017 at 09:35, Charles Chance <charles.chance(a)sipcentric.com>
wrote:
Hello,
Just to note, I had been looking into a similar issue before going on
holiday. I believe it may be fixed but need to do some further testing
today/tomorrow before committing. The backtrace would still be useful to
know that your issue is the same thing.
Cheers,
Charles
On 23 Oct 2017 7:35 a.m., "Daniel-Constantin Mierla" <miconda(a)gmail.com>
wrote:
> 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>om>:
>
>> 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
Mierlawww.twitter.com/miconda --
www.linkedin.com/in/miconda
>> Kamailio Advanced Training, Nov 13-15, 2017, in Berlin -
www.asipto.com
>> Kamailio World Conference -
www.kamailioworld.com
>>
>>
>
> --
> Daniel-Constantin
Mierlawww.twitter.com/miconda --
www.linkedin.com/in/miconda
> Kamailio Advanced Training, Nov 13-15, 2017, in Berlin -
www.asipto.com
> Kamailio World Conference -
www.kamailioworld.com
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users(a)lists.kamailio.org
>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
--
Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered
office: Faraday Wharf, Innovation Birmingham Campus, Holt Street,
Birmingham Science Park, Birmingham B7 4BB.