[SR-Users] Re: Failover with dialog dmq while dialog state 2

2024-05-17 Thread Björn Klasen via sr-users
of manually creating KDMQ messages to update the dialog module state in the cfg. Cheers, Henning From: Björn Klasen via sr-users <mailto:sr-users@lists.kamailio.org> Sent: Freitag, 10. Mai 2024 13:27 To: sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org> Cc: Björn Klasen

[SR-Users] Re: Failover with dialog dmq while dialog state 2

2024-05-10 Thread Björn Klasen via sr-users
mentioned, there is no replication of transaction state in tm. Cheers, Henning -- Björn Klasen, Senior Specialist (VoIP) TNG Stadtnetz GmbH, TNG-Technik Gerhard-Fröhler-Straße 12 24106 Kiel・Deutschland T +49 431 7097-10 F +49 431 7097-555 bkla...@tng.de<mailto:bkla...@tng.de> https://www.

[SR-Users] Failover with dialog dmq while dialog state 2

2024-05-07 Thread Björn Klasen via sr-users
none of the above is possible I really asking myself of a real use case of dialog dmq replication. -- Björn Klasen, Teamleitung NGN VoIP-Backbone TNG Stadtnetz GmbH, TNG-Technik Gerhard-Fröhler-Straße 12 24106 Kiel・Deutschland T +49 431 7097-10 F +49 431 7097-555 bkla...@tng.de https://www.tng.d

[SR-Users] Re: Dialog and DMQ on restart

2024-03-25 Thread Björn Klasen via sr-users
5.5.7 and 5.7.4 that have influence on the behavior. BR Björn Am 22.03.24 um 13:24 schrieb Ivan Baques via sr-users: Hi, i've the same problem on Kamailio 5.5.7, how do you resolved it? Best regards. El lun, 5 oct 2020, 11:34, Björn Klasen mailto:bkla...@tng.de>> escribió: Hi Henning, I

[SR-Users] Wrong documentation for module 'Userblacklist'

2024-03-20 Thread Björn Klasen via sr-users
, but the it has been changed back to Userblacklist. I wonder if nobody noticed that because the old commands do not work. BR, Björn -- Björn Klasen, Senior Specialist (VoIP) TNG Stadtnetz GmbH, TNG-Technik Gerhard-Fröhler-Straße 12 24106 Kiel・Deutschland T +49 431 7097-10 F +49 431 7097-555 bkla

Re: [SR-Users] No CDR is written on failover

2022-09-28 Thread Björn Klasen
-- Björn Klasen, Senior Specialist (VoIP) TNG Stadtnetz GmbH, TNG-Technik Projensdorfer Str. 324 24106 Kiel・Deutschland T +49 431 7097-10 F +49 431 7097-555 bkla...@tng.de www.tng.de <http://www.tng.de> Executive board (Geschäftsführer): Dr. Sven Willert (CEO/Vorsitz), Helmut Gertz,

[SR-Users] No CDR is written on failover

2022-09-09 Thread Björn Klasen
. I found nothing on the issue-page on github but maybe somebody knows something about it. BR Björn -- Björn Klasen, Senior Specialist (VoIP) TNG Stadtnetz GmbH, TNG-Technik Projensdorfer Str. 324 24106 Kiel・Deutschland T +49 431 7097-10 F +49 431 7097-555 bkla...@tng.de www.tng.de <h

Re: [SR-Users] Dialog and DMQ on restart

2020-10-05 Thread Björn Klasen
dialogs are also restored. BR, Björn Am 03.10.20 um 20:04 schrieb Henning Westerholt: Hello Björn, do you can observe any difference (e.g. with dmq.list_nodes, or on the network) in the two working/non-working cases? Cheers, Henning -- Björn Klasen, Specialist TNG Stadtnetz GmbH, Network

Re: [SR-Users] Dialog and DMQ on restart

2020-09-29 Thread Björn Klasen
it doesn't work and no dialogs are resynced BR, Björn Am 29.09.20 um 10:30 schrieb Björn Klasen: Hi Daniel, of course I can. This is the trace from node 1 where dialog is established. But after the restart I do not get any data on the KDMQ-request U 2020/09/29 10:21:43.460005 192.168.253.78:5062

Re: [SR-Users] Dialog and DMQ on restart

2020-09-29 Thread Björn Klasen
168.253.78:5062 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.253.78:5062;branch=z9hG4bKae4c.d5cf8a73.0. To: ;tag=9dd61ff61e802d8e2bef5f14621ef3c2.1adaf2d0. From: ;tag=3393f0703fb0ccaca74109ff37de39f5-505cb109. CSeq: 10 KDMQ. Call-ID: 535736740ae50ad1-32121@127.0.0.1. Server: k

Re: [SR-Users] Dialog and DMQ on restart

2020-09-28 Thread Björn Klasen
:5062] Sep 28 15:01:45 voip-lab-proxy02 /usr/sbin/kamailio[28828]: DEBUG: dmq [message.c:65]: ki_dmq_handle_message_rc(): dmq_handle_message peer found: dialog Am 28.09.20 um 15:07 schrieb Björn Klasen: Hi just had a log in debug log of the secondary node. Here I found the following lines Sep

Re: [SR-Users] Dialog and DMQ on restart

2020-09-28 Thread Björn Klasen
um 14:47 schrieb Björn Klasen: Hi everybody, I'm just testing Kamailio 5.4.1 with dialog replication over DMQ. This seems to work very good. Dialogs are replicated without problems. When I'm restarting one node I would have expected, that all dialogs are synced again, just like in dmq_usrloc

[SR-Users] Dialog and DMQ on restart

2020-09-28 Thread Björn Klasen
. After a restart the nodes dialog-list is empty. Did I miss somethin? Is there a special parameter that I have to set? BR, Björn -- Björn Klasen, Specialist TNG Stadtnetz GmbH, Network Management (VoIP) Projensdorfer Straße 324 24106 Kiel Germany T +49 431/ 530530 F +49 431/ 7097-555 mailto: bkla

Re: [SR-Users] How to handle BYE in case of serial fork

2020-09-11 Thread Björn Klasen
to store information about call branches for some time and then expire it later on. Cheers, Henning -- Björn Klasen, Specialist TNG Stadtnetz GmbH, Network Management (VoIP) Projensdorfer Straße 324 24106 Kiel Germany T +49 431/ 530530 F +49 431/ 7097-555 mailto: bkla...@tng.de http://www.tng.de

Re: [SR-Users] How to handle BYE in case of serial fork

2020-09-11 Thread Björn Klasen
I was not referring to dialog stateful routing e.g. with dialog module. I was referring to the loose_route() function in your kamailio.cfg (e.g. compare to the default cfg in github). Maybe you can quote the problematic BYE SIP message here. Cheers, Henning -- Björn Klasen, Specialist TNG Sta

Re: [SR-Users] How to handle BYE in case of serial fork

2020-09-11 Thread Björn Klasen
ailio doesn't know anything about it, so it does not reply". BTW, you should think about upgrading your Kamailio.  Cheers, Henning -- Björn Klasen, Specialist TNG Stadtnetz GmbH, Network Management (VoIP) Projensdorfer Straße 324 24106 Kiel Germany T +49 431/ 530530 F +49 431/ 7097-555 ma

[SR-Users] How to handle BYE in case of serial fork

2020-09-11 Thread Björn Klasen
the the situation with the second to-tag, we passing every call through SEMS now, because its B2B function rewrites the to-tag, so there is always only one to-tag towards the carrier A. But it's not the gold solution. I hope somebody can help me. BR, Björn -- Björn Klasen, Specialist TNG Stadtne