[SR-Users] Syncing Registration Database across Kamailio Pairs
Bastian Triller
bastian.triller at gmail.com
Tue Aug 9 19:08:26 CEST 2022
Maybe you have to enable another dmq_usrloc modparam [1]
[1]
https://www.kamailio.org/docs/modules/5.6.x/modules/dmq_usrloc.html#usrloc_dmq.p.replicate_socket_info
On Tue, Aug 9, 2022 at 4:38 PM harneet singh <hbilling at gmail.com> wrote:
> Hi Experts,
>
> We have been using Kamailio in an Active/Standby Pair(with Keepalived
> under the rugs moving the single Virtual IP to access the Active Kamailio)
> for sometime now. *Kamailio also acts as a Registrar for our webrtc
> endpoints. *
> It has been serving the purpose pretty well and now we have a requirement
> where we need to be syncing the Registration DB between Two Pairs of
> Kamailios.
>
> Kamailio-Active(*Pair 1*) -------- Kamailio-Standby(*Pair 1*)
> ||
> Kamailio-Active(*Pair 2*) -------- Kamailio-Standby(*Pair 2*)
>
> We generally keep the counterpart in the same Pair as a notifier( *modparam("dmq",
> "notification_address", "sip:PEER1_IP:5060")* ) so as to sync the dialogs
> and the userloc data too( *modparam("dmq_usrloc", "enable", 1) * ).
> In order to achieve the said requirement with the other Pair, we added
> another "*notification_address*" in the kamailio cfg. At this point, we
> ran into weird issues.
>
> *1. *With Kamailio ver *5.3.2, *the subsequent *notification_address *line
> in the cfg file, seemed to be overriding the previous one. Hence we see
> only the latter peer in the dmq list nodes.
> Example:
> modparam("dmq", "notification_address", "sip:*172.27.45.77*
> :5090")
> modparam("dmq", "notification_address", "sip:*172.27.45.200*
> :5090")
>
> In this case, the "*kamcmd dmq.list_nodes*" would show the local
> Machine and 172.27.45.200 as the only nodes in the output, ie *172.27.45.77
> is not showing up at all,* which is problematic, since the local
> machine(172.27.45.243 in our case) would not been able to send any dmq sync
> info to its peer(172.27.45.77) in the same Pair.
>
> To see if the above issue might have been addressed in later release, we
> upgraded to the latest Kamailio ver *5.6.0*
> *To our respite, the above issue no longer exists in the new version*(though
> not sure which immediate release after v 5.3.2 it would have been initially
> fixed.)
> This is where we have a new issue explained below:
>
> *2. *The registration data does get synced to the peer Kamailio in the
> same Pair, and also to the Kamailio instances in the other Pair. However,
> the *Socket* Parameter in "*kamctl ul show*" output shows *[not set] *even
> on the side where the websocket connection actually exists.
>
> [root at localhost ~]# *kamctl ul show *
> {
> "jsonrpc": "2.0",
> "result": {
> "Domains": [{
> "Domain": {
> "Domain": "location",
> "Size": 1024,
> "AoRs": [{
> "Info": {
> "AoR": "9008077221",
> "HashID": 1952082106,
> "Contacts": [{
> "Contact": {
> "Address": "sip:Harneet_qifir at 172.24.58.210",
> "Expires": 159,
> "Q": -1,
> "Call-ID": "vfli2uv8du3ppda73q5ppe",
> "CSeq": 106,
> "User-Agent": "EngageDigital",
> "Received": "sip:172.27.44.252:60070;transport=ws",
> "Path": "[not set]",
> "State": "CS_NEW",
> "Flags": 0,
> "CFlags": 0,
> * "Socket": "[not set]", <<<<<<<<<<<<<<<<<<<<<<*
> "Methods": 7071,
> "Ruid": "uloc-62f26e3b-2677-1",
> "Instance":
> "<urn:uuid:4fbd3e96-b4de-497b-886d-1ca8ffa016a4>",
> "Reg-Id": 1,
> "Server-Id": 0,
> "Tcpconn-Id": -1,
> "Keepalive": 0,
> "Last-Keepalive": 1660063892,
> "KA-Roundtrip": 0,
> "Last-Modified": 1660063892
> }
> }]
> }
> }
> ],
>
> In order to confirm that the socket actually exists on this Kamailio
> instance, I am pasting the below outputs from the same machine, where ws
> dump and even the native netstat confirms that.
>
> [root at localhost ~]# *netstat -tunelap | grep 60070*
> tcp 0 0 172.27.45.199:8080 172.27.44.252:*60070*
> *ESTABLISHED* 994 17322355 16230/kamailio
> [root at localhost ~]# *kamcmd ws.dump*
> {
> connections: {
> 1: ws:172.27.44.252:*60070* -> ws:172.27.45.199:8080 (state: *OPEN*,
> last used 24s ago, sub-protocol: sip)
> }
> info: {
> wscounter: 1
> truncated: no
> }
> }
>
> We do need to distinguish the actual Kamailio instance where the websocket
> connection actually exists, so as to route the call ahead from the same
> instance, or if it does not exist(and it's merely a sync'ed registration
> data received over DMQ Channel), then the Kamailio should route the call
> ahead to the Kamailio instance in the other Pair, which can then route it
> ahead to the Registered webrtc endpoint. We were hoping to use the Socket
> Parameter output, but for the said problem, unable to use the same as an
> indicator.
>
> *So what would be the best way to identify which Kamailio has the
> websocket connection with the Actual endpoint*? Should we rely on the
> output of netstat or ws.dump to infer that? I mean this needs to be done in
> kamailio.cfg for each call, so want to know the best way, or if there is
> completely different approach that can be suggested?
>
> Apologies for the long email, but any pointers will be much helpful.
>
> Thanks & Regards,
> Harneet Singh
>
> --
> "Once you eliminate the impossible, whatever remains, no matter how
> improbable, must be the truth" - Sir Arthur Conan Doyle
> __________________________________________________________
> Kamailio - Users Mailing List - Non Commercial Discussions
> * sr-users at lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> Edit mailing list options or unsubscribe:
> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20220809/7f0e8b6b/attachment.htm>
More information about the sr-users
mailing list