[kamailio/kamailio] Wrong dispatcher behaviour with two destinations with same URI (#2527)
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@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.
2 GW with the same IP in the same set is not fully supported, for example when using OPTION ping and matching for the response may not behave very well it will select one and not the other as it is only matching the URI. I do not see a very strait forward way to fix this.
It seems this is what you are facing the second one is DX, I wonder if adding a URI param to the URI would make a difference.
It could work since :
The SIP-URI is taken from the Transaction.
Try adding a fake param to differenciate them, it may be stored in the transaction URI.
Several functions like `ds_get_state(group, &uri)` are finding the GW in the set using the URI, if you have duplicates only one will be returned and it may not be the right one.
To add to @jchavanton remarks, besides trying with a different URI by using custom parameters, you can eventually try with a custom hostname and associating the IP with hostname via `dns_cache` modparam from `corex` module.
Otherwise, uri is the key to identify the record kept more or less from the initial version when the other attributes didn't exist, so using same value can lead to mixing matching them internally.
Hello Julien and Daniel,
Thank you for your clarifications.
I will be using this scenario for setting up an HA configuration with two kamailios in different machines, a replicated DB and two IPs that can jump between machines. I think i'll fix this with a script that will periodically check IPs in the host and only add add to dispatcher destinations URIs with sockets that belong to the host. That way i won't be dependent on the probing (we have some peers who don't accept probing) to see if the IP belongs to the machine and i won't have problems at the time Kamailio chooses a destination.
What do you think?
That should work.
If anyone wants to update the code to allow differentiation between two records with same URI, just make a PR. Also, if there is anything to discuss further, then use sr-users@lists.kamailio.org mailing list.
Closed #2527.
-
Daniel-Constantin Mierla -
duarterocha91
-
Julien Chavanton