[sr-dev] [kamailio/kamailio] Wrong dispatcher behaviour with two destinations with same URI (#2527)

[duarterocha91]

I’m doing some testing on Dispatcher in order to prepare it for HA setups with floating IPs on Kamailio version 5.4.1. 

In this scenario my calls must be sent to SET with the ID 2 : 



> SET: {
    ID: 2
    TARGETS: {
            DEST: {
                    URI: sip:GW_IP:5061
                    FLAGS: AX
                    PRIORITY: 0
                    ATTRS: {
                            BODY: duid=TB_MG03;socket=SOCKET_IP_1:5060
                            DUID: TB_MG03
                            MAXLOAD: 0
                            WEIGHT: 0
                            RWEIGHT: 0
                            SOCKET: SOCKET_IP_1:5060
                            SOCKNAME:
                            OBPROXY:
                    }
                    RUNTIME: {
                            DLGLOAD: 0
                    }
            }
            DEST: {
                    URI: sip:GW_IP:5061
                    FLAGS: AX
                    PRIORITY: 0
                    ATTRS: {
                            BODY: duid=TB_MG02;socket=SOCKET_IP_2:5060
                            DUID: TB_MG02
                            MAXLOAD: 0
                            WEIGHT: 0
                            RWEIGHT: 0
                            SOCKET: SOCKET_IP_2:5060
                            SOCKNAME:
                            OBPROXY:
                    }
                    RUNTIME: {
                            DLGLOAD: 0
                    }
            }
    }
}



As you can see, both gateways have the same URI but they have different sockets. In this scenario i tried to make a bunch of calls with this set as destination but all calls ended being delivered with socket "SOCKET_IP_2:5060" as oposed to doing a load balancing. This isn’t a real scenario since i wouldn’t want load balance for the same destination, but the objective is to show you the balance feature failing in this conditions, in order to help you debug the issue.



After that i tried a different scenario. This time i disabled the destination with DUID TB_MG02 and socket SOCKET_IP_2:5060 and made the same test.

> SET: {
    ID: 2
    TARGETS: {
            DEST: {
                    URI: sip:GW_IP:5061
                    FLAGS: AX
                    PRIORITY: 0
                    ATTRS: {
                            BODY: duid=TB_MG03;socket=SOCKET_IP_1:5060
                            DUID: TB_MG03
                            MAXLOAD: 0
                            WEIGHT: 0
                            RWEIGHT: 0
                            SOCKET: SOCKET_IP_1:5060
                            SOCKNAME:
                            OBPROXY:
                    }
                    RUNTIME: {
                            DLGLOAD: 0
                    }
            }
            DEST: {
                    URI: sip:GW_IP:5061
                    FLAGS: DX
                    PRIORITY: 0
                    ATTRS: {
                            BODY: duid=TB_MG02;socket=SOCKET_IP_2:5060
                            DUID: TB_MG02
                            MAXLOAD: 0
                            WEIGHT: 0
                            RWEIGHT: 0
                            SOCKET: SOCKET_IP_2:5060
                            SOCKNAME:
                            OBPROXY:
                    }
                    RUNTIME: {
                            DLGLOAD: 0
                    }
            }
    }
}


In this test all the calls ended up being delivered with SOCKET_IP_2 as the socket. This time no load balance was made and a disabled destination was used.

I’ve tried reversing the order of the destinations in the configuration and it now chooses socket SOCKET_IP_1 all the time.

If both destinations have different URIs none of this problems happen, only with two destinations with same address but different sockets.

Here are my dispatcher parameters, let me know if there is some config wrong : 

modparam("dispatcher", "flags", 2) // Failover support is enabled
modparam("dispatcher", "ds_ping_method", "OPTIONS")
modparam("dispatcher", "ds_hash_size", 8)
modparam("dispatcher", "db_url", DBURL)
modparam("dispatcher", "table_name", "TBK_DISPATCHER")
modparam("dispatcher", "setid_col", "TBK_NapGroupId")
modparam("dispatcher", "destination_col", "TBK_NapPeer")
modparam("dispatcher", "flags_col", "TBK_NapState") 
modparam("dispatcher", "priority_col", "TBK_NapPriority")
modparam("dispatcher", "attrs_col", "TBK_NapAttrs")
modparam("dispatcher", "ds_probing_mode", 3)
modparam("dispatcher", "ds_ping_interval", 10)
modparam("dispatcher", "ds_probing_threshold", 2)
modparam("dispatcher", "ds_inactive_threshold", 2) 
modparam("dispatcher", "ds_ping_reply_codes", "code=200;code=484;code=404") 
modparam("dispatcher", "ds_db_extra_attrs", "socket=TBK_Sap")
modparam("dispatcher", "ds_ping_from", "sip:PeerProbing at peer.probing")



What do you think might be the problem here? If you need any more info please let me know. HA setup is a really important feature for us to move forward and as such we need to assure that we use the correct socket.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2527
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-dev/attachments/20201022/5d5e0786/attachment-0001.htm>