[sr-dev] Multi Kamailio Scenarios

[E. Schmidbauer]

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 <bvisonl at gmail.com> 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
> bvisonl at gmail.com / (829)-664-5163
>
>
>
> On Thu, Sep 10, 2020 at 2:42 PM David Villasmil <
> david.villasmil.work at gmail.com> 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: david.villasmil.work at gmail.com
>> phone: +34669448337
>>
>>
>> On Thu, Sep 10, 2020 at 5:57 PM Benjamín Visón <bvisonl at gmail.com> 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
>>> bvisonl at gmail.com / (829)-664-5163
>>>
>>> _______________________________________________
>>> Kamailio (SER) - Development Mailing List
>>> sr-dev at lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
>>>
>> _______________________________________________
>> Kamailio (SER) - Development Mailing List
>> sr-dev at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
>>
> _______________________________________________
> Kamailio (SER) - Development Mailing List
> sr-dev at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-dev/attachments/20200910/89394336/attachment-0001.htm>