Closed #2760.
--
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#event-4909380088___
Kamailio (SER) - Development Mailing List
sr-dev@l
You can add a new parameter to tls_set_connect_server_id(), but if the same
`serverId` is provided, then I expect to be same certs (same client profile).
If you want to have many connections with the same profile, then 2nd parameter
makes sense. Otherwise, probably has to be some sort of global/
@miconda it was a very naïve modification so it just created a new connection
and never reused which was a horrible solution
Re-reading through tcp_main.c I had a spark of inspiration when I noticed that
`tcpconn_rm` checked if `c->extra_data` had a value other than 0 to determine
if `tls_tcpc
With your changes, does it create a new connection every time? Or connections
are reused in some cases?
You can make a pull request with your code and we can analyze/review/comment
there if can be integrated. The new behaviour should be guarded by a core
parameter, because the current one follo
I would agree its a connection reuse issue, #1107 is probably a more relevant
discussion to have.
As an experiment I tried a modified version of tcp_main.c with the connection
lookup modified to not return an existing connection and the expected behaviour
was observed.
Thinking the further th
As I understood from the previous comment, it is same target address, but you
want different tls connections with different certs.
SIP specifications decouple transport layer from SIP traffic, there is no
relation between a SIP request/transaction/dialog and transport layer (in this
case the TL
Debug output attached, in the full version from about line 8050 is the
dispatcher activity
[kamailio-debug-dispatcher-sni-full.log](https://github.com/kamailio/kamailio/files/6623779/kamailio-debug-dispatcher-sni-full.log)
[kamailio-debug-dispatcher-sni-dispatcher-activity.log](https://github.com/
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.hos
Can you set the `debug=3` global parameter, reproduce the scenario and attach
here all log messages printed by kamailio to syslog (there should be a log of
`DEBUG`)? It will help to troubleshoot and see what happens.
--
You are receiving this because you are subscribed to this thread.
Reply to
@arkadiam Pretty sure we are both trying to do same thing judging by your
dispatcher and routing config, multi domain telephony integration with a cloud
comms platform?
Its frustrating that SNI is being flakey as it works very nicely if you have a
single cert with multiple SAN's defined but th
I was half way through writing a less detailed version of a very similar issue
i am having too, having to send options presenting a specific servername and
cert
same environment as well (ubuntu 18.04, kam 5.5.0)
I have noticed that the xavp sni settings seems to only work on one thread as
well
### Description
Thank you for implementing #2413, I'm looking forward to use it.
I was trying it on a dev system. It works fine when the same TLS client needs
to be selected for ALL connections.
Having issue with it when connection expected to alternate between multiple
configured TLS clients.
12 matches
Mail list logo
