Re: [SR-Users] RTP voice failover
Hello, Unless I'm mistaken, there is no "out-of-the-box" solution. A way to do it would be an active/sdandby with keepalived + virtual IP + HA Redis setup. With Kubernetes, it could be possible, but I'm not sure it's well suited for a wide port range (usually 1 UDP ports), but I'm interested if somebody has already experience with it. Kind regards, Mathieu Bodjikian De : sr-users de la part de Evgeniy Envoyé : vendredi 26 juin 2020 15:38:40 À : sr-users@lists.kamailio.org Objet : [SR-Users] RTP voice failover Is that possible to implement RTP voice fail-over? In case RTP node goes down - the call should not be interrupted. This is kinda strange - but client want to have super redundant system. For example use 2 RTP nodes and simultaneously send 2 RTP stream over 2 nodes (yes - network traffic will increase) Or maybe is a way to recover UDP connections after a crash and replace node state. Maybe use a Kubernetes tools for that purpose ? Here what i found in mailing-list - https://lists.kamailio.org//pipermail/sr-users/2015-December/091006.html Many thanks for any hints to this topic. ___ 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
Re: [SR-Users] Kamailio 4.4.7 - LCR modules
Hello,
Indeed, the max gateway number is defaulting to 128 in the code :
#define DEF_LCR_GW_COUNT 128
You can modify it with a mod parameter :
modparam("lcr", "lcr_gw_count", 200)
Kind regards,
Mathieu Bodjikian
De : sr-users de la part de Laura
Envoyé : mercredi 28 août 2019 11:48:24
À : Kamailio (SER) - Users Mailing List
Objet : [SR-Users] Kamailio 4.4.7 - LCR modules
Hi guys,
on our enviromet we have 130+ gateway configured over the LCR_gw tables.
when we try to reload it.. we get error..
"Aug 28 09:40:36 vm-nextaitz-02 /usr/sbin/kamailio[3800]: ERROR: lcr
[lcr_mod.c:1511]: reload_tables(): too many gateways"
We reached some top values.. how can we modify it ?
Regards
___
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
[SR-Users] [DMQ] Sync DLG_STATE_CONFIRMED_NA dialog state ?
Hello, We are using DMQ module to sync dialogs between 3 Kamailio boxes. We are using last Kamailio version (5.2.3). >From our understanding, the state DLG_STATE_CONFIRMED_NA is not synced over >DMQ >(https://github.com/kamailio/kamailio/blob/a84a3ea618f0e602a8892c37fce7f4e72ab7371c/src/modules/dialog/dlg_dmq.c#L464) With containerized environement, the ACK's can go to any Kamailio instance, which lead to : On first box : -> INVITEreceived -> Dialog created + KDMQ sent (state DLG_STATE_UNCONFIRMED) -> 180 | 183 received -> Dialog updated + KDMQ sent (state DLG_STATE_EARLY) -> 200 received -> Dialog updated + KDMQ NOT sent (DLG_STATE_CONFIRMED_NA) On second box : -> ACK received : - next_state_dlg(): bogus event 6 in state 2 for dlg - dialog not updated - KDMQ with state DLG_STATE_CONFIRMED not sent On first box, after timeout : -> After timeout : - dialg with incorrect timeouts (since box2 didn't send dialog update) - tm sends BYE in both ways - bye_reply_cb(): inconsitent dlg timer data on dlg We see two solutions : - We add DLG_STATE_CONFIRMED_NA to states we sync on dlg_dmq_replicate_action - We manage to route the ACK on the same instance that received first INVITE (could be tricky) Which one is preferable ? Kind regards, Mathieu Bodjikian ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
