[sr-dev] Multi Kamailio Scenarios

Benjamín Visón bvisonl at gmail.com
Thu Sep 10 18:56:48 CEST 2020


I am setting up a redundant active/active environment and I am in need of
having 2 kamailios operate as full proxies (meaning both of them will
accept registrations).

I am using DMQ in order to keep htables synched as well as dialogs.

For locations, I have a PostgreSQL database with the registrations.

My problem is that since both kamailios are accepting registrations the
UACs are only able to receive packets from the UAS on which they are
registered. Therefore when let's say UAC-1 registers to Kamailio A and it
tries to call UAC-2 which is registered on Kamailio B nothing happens
because UAC-2 receives the INVITE from Kamailio A and just ignores them.

I've spent almost a month trying to play with inter-kamailio communication
(that is, detecting these types of scenarios and sending the INVITE to
Kamailio B and have Kamailio B send the INVITE to UAC-2) but there are a
LOT of things that are not working properly let alone having to keep track
of all the dialog information and to/from tags and doing proper route of
all ACK/BYE/CANCEL, etc.

My question is, is there a way to achieve this scenario where multiple
kamailios can coexist with all responsibilities?


Things I've tried:

   - Keep track of to/from tag in an htable and forward requests based on
   who sent the request
   - Use append_branches to handle multiple AOR (with the possibility of 1
   user having multiple registrations in different kamailios)
   - Manually tweaking $ru/$du based on what type of request is and who is
   it destined to.


Any orientation will be appreciated as this is a crucial piece of the
project I'm working on.

Saludos,

[image: Facebook] <https://www.facebook.com/bvisonl>[image: Twitter]
<https://twitter.com/benjaminvison>[image: Instagram]
<https://instagram.com/bvisonl/>

Benjamín Visón / IT Engineer / Software Developer
bvisonl at gmail.com / (829)-664-5163
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-dev/attachments/20200910/f9cbf8e9/attachment-0001.htm>


More information about the sr-dev mailing list