@arkadiam Pretty sure we are both trying to do same thing judging by your dispatcher and routing config, multi domain telephony integration with a cloud comms platform?

Its frustrating that SNI is being flakey as it works very nicely if you have a single cert with multiple SAN's defined but that less than ideal from a management point of view (but doesnt seem to have the performance hit loading multiple certs has #2312 )

For sake of completeness my virtually identical config is as follows: ```event_route[tm:local-request] { if(is_method("OPTIONS") && $ru =~ "vendor.com") { xlogl("L INFO", "Dispatcher Pinging ruri: $ru turi: $tu furi: $fu"); append_hf("Contact: sip:$fd:5061;transport=tls\r\n"); tls_set_connect_server_id($fd); xlogl("L INFO","SNI ID: $fd"); } } ```

Certainly, i spent yesterday debugging and going through the logs and im thinking the issue may be the (ab)use of dispatcher to ping the same destination presenting as different domains. The destinations are intentially the same in the sample dispatcher.list in the first post

```1 sip:sip1.host.com;transport=tls 0 1 socket=tls:111.222.233.11:5061;ping_from=sip:my-domain-01.com 1 sip:sip2.host.com;transport=tls 0 2 socket=tls:111.222.233.12:5061;ping_from=sip:my-domain-01.com 1 sip:sip3.host.com;transport=tls 0 3 socket=tls:111.222.233.13:5061;ping_from=sip:my-domain-01.com 2 sip:sip1.host.com;transport=tls 0 1 socket=tls:111.222.233.21:5061;ping_from=sip:my-domain-02.com 2 sip:sip2.host.com;transport=tls 0 2 socket=tls:111.222.233.22:5061;ping_from=sip:my-domain-02.com 2 sip:sip3.host.com;transport=tls 0 3 socket=tls:111.222.233.23:5061;ping_from=sip:my-domain-02.com```

What we are both trying to achieve is I believe integration with Teams using SNI to provide connectivity to multiple domain names. I have been running in production for a couple of years now a solution based on using a single cert and lots of SAN's but that i becoming a management nightmare and using a cert per domain served is far preferable. DR (Direct Routing) has a primary signalling domain and two failover domains (hence dispatcher is ideal for this). Connectivity is monitored by mutually verifying the TLS connection where the Server (kamailio) must present a valid cert whose SN or SAN must match the expected SNI server name from the client (DR SBC), for inbound traffic this works fine, but on outbound traffic the same rules apply meaning that each domain we wish to serve has to have its own connection which has been initialised to utilise the corresponding [client:any] entry with the appropriate server name configured. DR's second level connection state involves mutually pinging each end, but DR only sends pings on the receipt of valid ping from the kamailio, which doesnt happen as my-domain02.com presents as my-domain01.com.

I added some additional LM_DBG statements to the TLS module as well as compiling with the TLS_WR_DEBUG and TLS_RD_DEBUG defines enabled to help track the flow through the code initially i noticed calls to `ksr_tls_set_connect_server_id` were not always setting `_ksr_tls_connect_server_id` so i commented out the `if(_ksr_tls_connect_server_id.len>=srvid->len)` block and the value was consistently set. However i was seeing the TLS connection initalise only 3 times, using the set server ID for the first dispatcher set, and never the second, even though i could see clearly the server id being set, the logs jump straight to writing over the existing connection. Which leads me to believe as the destination (and probably sending port) is the same for each dispatcher address set then the connection will be reused. (#1107 seems to be an accurate description of what i have observed). Which leads me to wonder; if an existing matching connection needs to be closed when the server id is set by `ksr_tls_set_connect_server_id` or if an additional connection matching mode could be implemented which took a from address into consideration whilst matching.

I will revert my changes and post the log output here

As I understood from the previous comment, it is same target address, but you want different tls connections with different certs.

SIP specifications decouple transport layer from SIP traffic, there is no relation between a SIP request/transaction/dialog and transport layer (in this case the TLS connection). Even more the specs recommend connection reuse, which is done here.

Practically, if the target is the same, then kamailio creates a single connection to it and it will be used for all traffic sent to the target, irrelevant of the SIP From headers or different dispatcher groups, a.s.o.

Looking at dispatcher records provided by @arkadiam, seems to be same case for him.

You can try to have different listen sockets for domains, if you have a few of them should be ok.

Otherwise, the tcp (tls) connection management code has to be changed, it may impact several components. It has to be coded in C.

Over all, it seems not to be an issue related to `ksr_tls_set_connect_server_id()`, if no other new information shows up soon to indicate a different conclusion, this issue can be closed.

With your changes, does it create a new connection every time? Or connections are reused in some cases?

You can make a pull request with your code and we can analyze/review/comment there if can be integrated. The new behaviour should be guarded by a core parameter, because the current one follows the specs. Adding a new core parameter requires changing lex/yacc files, I can do it if you are not familiar with them, just introduce a global variable to use it in IF conditions.

You can add a new parameter to tls_set_connect_server_id(), but if the same `serverId` is provided, then I expect to be same certs (same client profile). If you want to have many connections with the same profile, then 2nd parameter makes sense. Otherwise, probably has to be some sort of global/module parameter to specify that matching has to be done also on TLS profile, not only on destination address for tls connections. Having mixed matching (with or without serverid) at the same time, might bring in more complexity. Anyhow, up to you how you implement, make a PR then we can discuss further there.