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
--
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/2760#issuecomment-857528638
_______________________________________________
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev