9 Jun
2021
9 Jun
'21
12:13 p.m.
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