Thank you Emmanuel, I am testing out your suggestion but I am encountering an issue and I would like a little guidance if possible. I've setup an edge proxy doing just a load balance with the dispatcher module. Behind that proxy there is another kamailio which is acting as a registrar. I've confirmed that the proxy is adding the path header.
I have a couple of questions: - Can the registrars behind the proxy listen only to the internal network address or do they need a public IP as well? - If the registrars are in an internal network along with the edge proxy, shouldn't the proxy add the internal address as the Path instead of the public? - I am seeing that despite the header Path being added, the registrar is trying to relay the INVITE messages to the UAC and not to the proxy, I am using several parameters of the registrar module in the registrar servers such as: use_path(1), path_mode(0), path_use_received(1), path_chek_local(1). - Do I have to still tweak the request manually (that is messing with $du/$ru) in order for the packet to go back to the proxy? I know these are a lot of questions but if you could maybe guide me to some samples, related issues or documentation I would appreciate it, I am sure that others that encounter these issues might benefit as well. 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 [email protected] / (829)-664-5163 On Thu, Sep 10, 2020 at 9:38 PM E. Schmidbauer <[email protected]> wrote: > If you want redundant registrars, you should add an edge proxy (or two if > you want redundant edge proxies) and use the path header. This way the user > location record includes a "path" back through the proxy which the UAC > connected to. > > On Thu, Sep 10, 2020, 7:29 PM Benjamín Visón <[email protected]> wrote: > >> Hello David, >> >> I am able to get the INVITE go from one kamailio to the other just fine >> and the call actually connects, the problem arises when, for example, a 200 >> OK (SDP) message is delivered back to the caller, this SDP doesn't have the >> necessary information for the ACK to route itself back to the caller. >> Therefore I am having to keep track of each to/from tag (in an htable) and >> know on which kamailio those to/from tags are being handled so that I can >> intercept messages and then re-route them since simply calling t_relay >> would not work. >> >> This is getting very messy and there are a lot of cases in which the >> scenario is not working as desired (for example, a BYE message is behaving >> very in a very strange manner if the caller is the one that hangs up the >> call). >> >> If you could get me those PPT I would really appreciate it! I am not a >> SIP guru but I can defend myself. I just can't seem to understand properly >> how to route these replies/requests. >> >> If needed, tomorrow I will try to capture a few scenarios with sngrep so >> that I can share them, I have multiple scenarios with multiple problems but >> I will try to pick the one that's working the best. >> >> >> 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 >> [email protected] / (829)-664-5163 >> >> >> >> On Thu, Sep 10, 2020 at 2:42 PM David Villasmil < >> [email protected]> wrote: >> >>> Hello, >>> >>> What happens when you send the INVITE from Kamailio1 to Kamailio2? that >>> should work properly. It is a simple call scenario, unless you have some >>> other requirement? >>> There's even some PPTs showing how that works (which i can't find right >>> now) >>> >>> Regards, >>> >>> David Villasmil >>> email: [email protected] >>> phone: +34669448337 >>> >>> >>> On Thu, Sep 10, 2020 at 5:57 PM Benjamín Visón <[email protected]> >>> wrote: >>> >>>> 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 >>>> [email protected] / (829)-664-5163 >>>> >>>> _______________________________________________ >>>> Kamailio (SER) - Development Mailing List >>>> [email protected] >>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev >>>> >>> _______________________________________________ >>> Kamailio (SER) - Development Mailing List >>> [email protected] >>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev >>> >> _______________________________________________ >> Kamailio (SER) - Development Mailing List >> [email protected] >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev >> > _______________________________________________ > Kamailio (SER) - Development Mailing List > [email protected] > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev >
_______________________________________________ Kamailio (SER) - Development Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
