You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
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: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—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.