Dispatcher SNI Questions - sr-users

5 Jan 2021

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.