[SR-Users] TLS connection from Chrome to Kamailio fails

2020-10-17 Thread Juha Heinanen
What I wrote in below, is not correct. (1) Pointing Chrome to https://:5061 does result in successful handshake: Oct 17 17:53:06 lohi /usr/bin/sip-proxy[13274]: INFO: tls [tls_domain.c:751]: sr_ssl_ctx_info_callback(): SSL handshake started Oct 17 17:53:06 lohi /usr/bin/sip-proxy[13274]:

Re: [SR-Users] TLS connection from Chrome to Kamailio fails

2020-10-16 Thread Juha Heinanen
Jeff Bilyk writes: > https://lists.kamailio.org/pipermail/sr-users/2013-March/077235.html may > contain a helpful workaround, Jeff, Thanks for your reply. I do have tcp_accept_aliases=no and this problems appears before event_route [xhttp:request], that is, already during TLS handshake. --

Re: [SR-Users] TLS connection from Chrome to Kamailio fails

2020-10-16 Thread Juha Heinanen
Henning Westerholt writes: > Interesting. Does e.g. 5.4 still works for you? Might be then a > regression in trunk. Same problem with 5.4. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org

[SR-Users] TLS connection from Chrome to Kamailio fails

2020-10-16 Thread Juha Heinanen
Simple way to show this problem without any WebRTC SIP client is to point Chrome browser to K's TLS listening port: https://:5061 and look with wireshark or tshark how the handshake gets terminated by Chrome right after Server Hello. The same with Firefox works fine. -- Juha

Re: [SR-Users] TLS connection from Chrome to Kamailio fails

2020-10-16 Thread Jeff Bilyk
Hello Juha, https://lists.kamailio.org/pipermail/sr-users/2013-March/077235.html may contain a helpful workaround, Jeff On Fri, Oct 16, 2020, 11:14 AM Juha Heinanen wrote: > Henning Westerholt writes: > > > Interesting. Does e.g. 5.4 still works for you? Might be then a > > regression in

Re: [SR-Users] TLS connection from Chrome to Kamailio fails

2020-10-16 Thread Henning Westerholt
16, 2020 5:07 PM To: Kamailio (SER) - Users Mailing List Subject: [SR-Users] TLS connection from Chrome to Kamailio fails Simple way to show this problem without any WebRTC SIP client is to point Chrome browser to K's TLS listening port: https://:5061 and look with wireshark or tshark how