Re: [SR-Users] shared dialogs

2017-10-26 Thread : Paolo Visintin - Time-Net S.r.l.
Hello!
sorry for no reply, I've gone out for business , I'll try to replicate in
the next few days and come back to you



paolo visintin
direttore tecnico
--
timenet srl | www.timenet.it | tel 05711738000
assistenza tecnica: assiste...@timenet.it
ufficio commerciale: sa...@timenet.it
ufficio amministrativo: contabil...@timenet.it
twitter.timenet.it | linkedin.timenet.it


2017-10-25 14:53 GMT+02:00 Charles Chance :

> 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  > 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" 
>> 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/pass_fd.c:277]: receive_fd(): EOF on 15
>>>  0(1549) ALERT:  [main.c:742]: handle_sigs(): child process 1570
>>> exited by a signal 11
>>>  0(1549) ALERT:  [main.c:745]: handle_sigs(): core was generated
>>>  0(1549) INFO:  [main.c:768]: handle_sigs(): terminating due to
>>> SIGCHLD
>>>  5(1571) INFO:  [main.c:823]: sig_usr(): signal 15 received
>>> ...
>>>  1(1567) INFO:  [main.c:823]: sig_usr(): signal 15 received
>>>  0(1549) CRITICAL:  [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 :
>>>
 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@lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>
>
>
> Sipcentric Ltd. Company registered in England 

Re: [SR-Users] shared dialogs

2017-10-23 Thread Charles Chance
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" 
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/pass_fd.c:277]: receive_fd(): EOF on 15
>  0(1549) ALERT:  [main.c:742]: handle_sigs(): child process 1570
> exited by a signal 11
>  0(1549) ALERT:  [main.c:745]: handle_sigs(): core was generated
>  0(1549) INFO:  [main.c:768]: handle_sigs(): terminating due to
> SIGCHLD
>  5(1571) INFO:  [main.c:823]: sig_usr(): signal 15 received
> ...
>  1(1567) INFO:  [main.c:823]: sig_usr(): signal 15 received
>  0(1549) CRITICAL:  [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 :
>
>> 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@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.
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] shared dialogs

2017-10-23 Thread Daniel-Constantin Mierla
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/pass_fd.c:277]: receive_fd(): EOF on 15
>  0(1549) ALERT:  [main.c:742]: handle_sigs(): child process 1570
> exited by a signal 11
>  0(1549) ALERT:  [main.c:745]: handle_sigs(): core was generated
>  0(1549) INFO:  [main.c:768]: handle_sigs(): terminating due to
> SIGCHLD
>  5(1571) INFO:  [main.c:823]: sig_usr(): signal 15 received
> ...
>  1(1567) INFO:  [main.c:823]: sig_usr(): signal 15 received
>  0(1549) CRITICAL:  [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  >:
>
> 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  -- 
> 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 Mierla
www.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@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] shared dialogs

2017-10-18 Thread : Paolo Visintin - Time-Net S.r.l.
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/pass_fd.c:277]: receive_fd(): EOF on 15
 0(1549) ALERT:  [main.c:742]: handle_sigs(): child process 1570
exited by a signal 11
 0(1549) ALERT:  [main.c:745]: handle_sigs(): core was generated
 0(1549) INFO:  [main.c:768]: handle_sigs(): terminating due to
SIGCHLD
 5(1571) INFO:  [main.c:823]: sig_usr(): signal 15 received
...
 1(1567) INFO:  [main.c:823]: sig_usr(): signal 15 received
 0(1549) CRITICAL:  [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 :

> 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
>
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] shared dialogs

2017-10-18 Thread Yuriy Gorlichenko
As i remember dialog module has db based interpretation. You can share it
via db.

On Oct 18, 2017 10:16, ": Paolo Visintin - Time-Net S.r.l." <
paolo.visin...@timenet.it> 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
>
> ​Thanks in advance
>
> Paolo
> ​
>
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users