giangi created an issue (kamailio/kamailio#4236)
### Description
The mode flag value 16 (int) in `ds_is_from_list()` is supposed to provide a "best matching" candidate, however it does not seem to recognize anything other than exact matches.
### Troubleshooting
#### Reproduction
With the following `dispatcher.list`
``` # setid(int) destination(sip uri) flags(int,opt) priority(int,opt) attributes(str,opt)
1 sip:127.1.2.3:5060 1 sip:127.1.2.3:5060;transport=tcp ```
The following invocations result in a match
``` ds_is_from_list("-1", "16", "sip:127.1.2.3:5060"); ds_is_from_list("-1", "16", "sip:127.1.2.3:5060;transport=tcp"); ```
while others, e.g. some with some mismatching ports, but a valid address, fail to match
``` ds_is_from_list("-1", "16", "sip:127.1.2.3:12345"); ds_is_from_list("-1", "16", "sip:127.1.2.3:12345;transport=tcp"); ```
### Possible Solutions
The code of `ds_is_addr_from_set()` from `src/modules/dispatcher/dispatch.c` has some suspicious `continue` while evaluating the "strictness score" of nodes and deciding upon the best match. If I am not mistaken they may cause the code that updates the `ds_strictest_node` to never get executed, thus not providing any match at all.
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
``` version: kamailio 5.8.6 (x86_64/linux) flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_SEND_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled with gcc 12.2.0 ```
* **Operating System**: Debian 12 "bookworm"
miconda left a comment (kamailio/kamailio#4236)
I haven't implemented that matching mode and it was a bit weird from the beginning (weight of matching socket is higher than port+proto), anyhow, what you commented seemed valid, the continue statements were preventing the setting of a matching node. I pushed a commit for it, try to see if it solves it.
Closed #4236 as completed.
giangi left a comment (kamailio/kamailio#4236)
Thank you for looking into this @miconda ! I just tried and a nightly Debian bookworm package (specifically `6.1.0~dev1+bpo12.20250614024421.153`) seems to behave as intended.
To be honest, I did not notice the weirdness of the mode, but I came across it while looking for a way to make `ds_is_from_list()` look up the originating set ID of a request accomodating both
* Simple address-only matches * Exact matches for more strict sources, with the potential of associating the same address to different sets based on port/transport
without resorting to something like
``` if (!ds_is_from_list("-1", "0")) { ds_is_from_list("-1", "3"); } ```
I am currently happy with the "workaround", but maybe when this commit makes it into a release I will give it a spin.