[SR-Users] Dispatcher SNI Questions

Hi All Is it possible to explicitly define the tls cert to be used per destination by dispatcher? I'm attempting to integrate with a service that requires domain name presented to match that of the cert. Where the use of dispatcher is probably not as intended anyway as it targets the same set of destinations multiple times (primary and secondary endpoints for the service im integrating with), with multiple distinct set id's (basically a set per customer for multi tenancy) which expects a sip ping per account to verify that connection is alive and healthy. #Example Dispatcher list #Account 1 1 sip:a.cloudservice.com:5061;transport=tls 8 1 socket=tls:10.0.0.2:5061;ping_sni=sip.account1.com;ping_from=sip:sip.account1.com:5061 1 sip:b.cloudservice.com:5061;transport=tls 8 1 socket=tls:10.0.0.2:5061;ping_sni=sip.account1.com;ping_from=sip:sip.account1.com:5061; #Account 2 2 sip:a.cloudservice.com:5061;transport=tls 8 1 socket=tls:10.0.0.2:5061;ping_sni=sip.account2.com;ping_from=sip:sip.account2.com:5061; 2 sip:b.cloudservice.com:5061;transport=tls 8 1 socket=tls:10.0.0.2:5061;ping_sni=sip.account2.com;ping_from=sip:sip.account2.com:5061; Currently I'm running a solution based around certs with multiple SAN (subject alternative name) defined, but this is a pain to administrate, and not as scalable as I would like. I want to be able to define multiple client:any tls profiles and explicitly send via that profile. Its easy enough to do that in config using the tls xavps to define a server name and/or id. But for the sip options ping by dispatcher to work you need to specify the server name or id before the tm:local-request event route fire's. I've resorted to hacking away at dispatcher to see what would happen if I set the tls server name or id before the OPTIONS message is sent, and it works great for the first tls client profile matched, but any others you define re-use the initial tcp connection so reuses the first connections tls config, thus presenting the wrong cert (I'm probably wrong but logs show only one tls complete_init() related to dispatcher pings and the second set's pings skips all the tls init logging so suggests some thing is cached/reused, and logging on the service indicates cert name mismatch with set1s cert being offered) So I've hit a bit of a dead end, is there a way to force a new tcp connection per server name/id I fear outbound SNI might be a bit of a can of worms, for it to work nicely with dispatcher as is, would be an extension of the proto:host:port format to include a name or id, maybe something like: tls(name=sub.domain.com):10.0.0.5:5061 But that looks like it would have a lot of wide reaching knock-on effects, so setting it as an attribute like ping_from works fine as I'm currently doing, if I could force a new connection from dispatch.c.... The other thing that's occurred to me is that it might be better to stop trying to adapt a small percentage of dispatcher's functionality and trying to hammer a round peg into a square hole and instead try and create a new module similar to dispatcher in so much that it sends pings (that's all I really need in this case) and use dispatcher as intended with a single set of non-repeated destinations for routing. This would also allow much simpler integration with MS teams (if added ability to set contact address on the background pings) as well as the service im trying to integrate, and a more natural data set to be used as in my example you can see the only difference is the customers domain between each set. How I would imagine it to work would be to create a tls connection per customer domain, then iterate through the connections per destination in pseudo json the data would look like this: { Destinations:[ [1,["a.cloudservice.com","b.cloudservice.com"]], [2,["sip.pstnhub.microsoft.com", "sip2.pstnhub.microsoft.com", "sip3.pstnhub.microsoft.com"] ], Sources:[ {uri:"sip.account1.com",destinationMapping:[1]}, {uri:"sip.account2.com",destinationMapping:[1,2]} ] } And would just run in the background sending pings with SNI support, and if based on dispatcher should make it easy enough adapt things like the destination up and down event routes, and would allow me to use Kamailio much like I would use nginx for web stuff as a reverse proxy and handle TLS offload on my edge gateway proxy. Any thoughts?, im frustratingly close to having something that will do if I could get a new connection to be created, but I fear my use case might be sufficiently different from dispatchers to make a new module a sensible approach.. Regards Tim.