Freeswitch use DTLS v1.0 instead of DTLS v1.2
Hello guys, I'm facing a big trouble for several hours ago and need help.... I'm using Freeswitch v1.10.2 with webRTC successfully installed and running. On the user/webphone side, I'm using Chrome 81.0.4044.138. Incoming and outgoing calls works fine with my webphone stack on my browsers (Firefox, Chrome). No warnings or errors at both sides. But when I do the following scenario with a webphone that can manage several calls at the same time (multi-line feature), it does not work : 1. make a first call routed to a webrtc extension, answer it and keep it connected 2. make a second call routed to the same extension, do not answer and keep the first call connected 3. make a third call routed to the same extension and hold the first line to accept this new call=> when I try to answer this 3rd call, the call is always dropped After digging into logs, and packets captured with wireshark, I found that when the freeswitch try to exchange with the browser to negociate SRTP flow for the 3rd call, it use DTLS v1.0 protocol (instead of v1.2) : Unfortunately, support for DTLS v1.0 seems to have been dropped on my webphone/browser side and the freeswitch fail on last DTLS exchange with this logs : [INFO] switch_rtp.c:3736 Activate RTP/RTCP audio DTLS client [INFO] switch_rtp.c:3903 Changing audio DTLS state from OFF to HANDSHAKE [...] [ERR] switch_rtp.c:3266 audio Handshake failure 1. This may happen when you use legacy DTLS v1.0 (legacyDTLS channel var is set) but endpoint requires DTLS v1.2. On freeswitch side, I found only one option linked to the DTLS version (legacyDTLS, as written in logs) which I never set in my config. I checked my open ssl version on the freeswitch server (1.1.1d). The thing that is disturbing to me is that if I hold the first call and answer the second call, it works well. The issue occurs only for the third call and after a missed/refused call while still connected with first call in parallel. Digging into freeswitch source, I found that it seems to use version-flexible DTLS methods of openssl (DTLS_server_method() and DTLS_client_method()) and I cannot see how to quicly and simply always force DTLS v1.2 ? Have any of you ever had this kind of problem or know how to solve it ? Regards, FX
Hi, As you look familiar with the source code, you may add SSL_CTX_set_min_proto_version(dtls->ssl_ctx, DTLS1_2_VERSION); as a quick hack in switch_rtp.c around where DTLS_server_method() / DTLS_client_method() are called. But it looks like a bug, you should create an issue on github. Best Regards, -- Valli A. Vallimamod SIP Solutions vma@sip.solutions linkedin.com/in/vallimamod .
On 12 May 2020, at 19:43, François-Xavier Geneste <fx.geneste@telemaque.fr> wrote:
Hello guys,
I'm facing a big trouble for several hours ago and need help.... I'm using Freeswitch v1.10.2 with webRTC successfully installed and running. On the user/webphone side, I'm using Chrome 81.0.4044.138. Incoming and outgoing calls works fine with my webphone stack on my browsers (Firefox, Chrome). No warnings or errors at both sides.
But when I do the following scenario with a webphone that can manage several calls at the same time (multi-line feature), it does not work :
• make a first call routed to a webrtc extension, answer it and keep it connected • make a second call routed to the same extension, do not answer and keep the first call connected • make a third call routed to the same extension and hold the first line to accept this new call=> when I try to answer this 3rd call, the call is always dropped After digging into logs, and packets captured with wireshark, I found that when the freeswitch try to exchange with the browser to negociate SRTP flow for the 3rd call, it use DTLS v1.0 protocol (instead of v1.2) :
<lnancehjiedpjici.png>
Unfortunately, support for DTLS v1.0 seems to have been dropped on my webphone/browser side and the freeswitch fail on last DTLS exchange with this logs :
[INFO] switch_rtp.c:3736 Activate RTP/RTCP audio DTLS client [INFO] switch_rtp.c:3903 Changing audio DTLS state from OFF to HANDSHAKE [...] [ERR] switch_rtp.c:3266 audio Handshake failure 1. This may happen when you use legacy DTLS v1.0 (legacyDTLS channel var is set) but endpoint requires DTLS v1.2.
On freeswitch side, I found only one option linked to the DTLS version (legacyDTLS, as written in logs) which I never set in my config. I checked my open ssl version on the freeswitch server (1.1.1d).
The thing that is disturbing to me is that if I hold the first call and answer the second call, it works well. The issue occurs only for the third call and after a missed/refused call while still connected with first call in parallel.
Digging into freeswitch source, I found that it seems to use version-flexible DTLS methods of openssl (DTLS_server_method() and DTLS_client_method()) and I cannot see how to quicly and simply always force DTLS v1.2 ?
Have any of you ever had this kind of problem or know how to solve it ?
Regards,
FX
_________________________________________________________________________
The FreeSWITCH project is sponsored by SignalWire https://signalwire.com Enhance your FreeSWITCH install with disruptive priced SMS and PSTN services. Build your next product on our scalable cloud platform.
Join our online community to chat in real time https://signalwire.community
Professional FreeSWITCH Services sales@freeswitch.com https://freeswitch.com
Official FreeSWITCH Sites https://freeswitch.com/oss https://freeswitch.org/confluence https://cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users https://freeswitch.com
It's already there, unless your version of OpenSSL doesn't have DTLS v1.2, Its wrapped in an ifdef HAVE_OPENSSL_DTLSv1_2_method /b On Tue, May 19, 2020 at 4:56 AM Valli A. Vallimamod <vma@vallimamod.org> wrote:
Hi,
As you look familiar with the source code, you may add
SSL_CTX_set_min_proto_version(dtls->ssl_ctx, DTLS1_2_VERSION);
as a quick hack in switch_rtp.c around where DTLS_server_method() / DTLS_client_method() are called.
But it looks like a bug, you should create an issue on github.
Best Regards, -- Valli A. Vallimamod SIP Solutions vma@sip.solutions linkedin.com/in/vallimamod .
On 12 May 2020, at 19:43, François-Xavier Geneste < fx.geneste@telemaque.fr> wrote:
Hello guys,
I'm facing a big trouble for several hours ago and need help.... I'm using Freeswitch v1.10.2 with webRTC successfully installed and running. On the user/webphone side, I'm using Chrome 81.0.4044.138. Incoming and outgoing calls works fine with my webphone stack on my browsers (Firefox, Chrome). No warnings or errors at both sides.
But when I do the following scenario with a webphone that can manage several calls at the same time (multi-line feature), it does not work :
• make a first call routed to a webrtc extension, answer it and keep it connected • make a second call routed to the same extension, do not answer and keep the first call connected • make a third call routed to the same extension and hold the first line to accept this new call=> when I try to answer this 3rd call, the call is always dropped After digging into logs, and packets captured with wireshark, I found that when the freeswitch try to exchange with the browser to negociate SRTP flow for the 3rd call, it use DTLS v1.0 protocol (instead of v1.2) :
<lnancehjiedpjici.png>
Unfortunately, support for DTLS v1.0 seems to have been dropped on my webphone/browser side and the freeswitch fail on last DTLS exchange with this logs :
[INFO] switch_rtp.c:3736 Activate RTP/RTCP audio DTLS client [INFO] switch_rtp.c:3903 Changing audio DTLS state from OFF to HANDSHAKE [...] [ERR] switch_rtp.c:3266 audio Handshake failure 1. This may happen when you use legacy DTLS v1.0 (legacyDTLS channel var is set) but endpoint requires DTLS v1.2.
On freeswitch side, I found only one option linked to the DTLS version (legacyDTLS, as written in logs) which I never set in my config. I checked my open ssl version on the freeswitch server (1.1.1d).
The thing that is disturbing to me is that if I hold the first call and answer the second call, it works well. The issue occurs only for the third call and after a missed/refused call while still connected with first call in parallel.
Digging into freeswitch source, I found that it seems to use version-flexible DTLS methods of openssl (DTLS_server_method() and DTLS_client_method()) and I cannot see how to quicly and simply always force DTLS v1.2 ?
Have any of you ever had this kind of problem or know how to solve it ?
Regards,
FX
_________________________________________________________________________
The FreeSWITCH project is sponsored by SignalWire https://signalwire.com Enhance your FreeSWITCH install with disruptive priced SMS and PSTN services. Build your next product on our scalable cloud platform.
Join our online community to chat in real time https://signalwire.community
Professional FreeSWITCH Services sales@freeswitch.com https://freeswitch.com
Official FreeSWITCH Sites https://freeswitch.com/oss https://freeswitch.org/confluence https://cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users https://freeswitch.com
_________________________________________________________________________
The FreeSWITCH project is sponsored by SignalWire https://signalwire.com Enhance your FreeSWITCH install with disruptive priced SMS and PSTN services. Build your next product on our scalable cloud platform.
Join our online community to chat in real time https://signalwire.community
Professional FreeSWITCH Services sales@freeswitch.com https://freeswitch.com
Official FreeSWITCH Sites https://freeswitch.com/oss https://freeswitch.org/confluence https://cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users https://freeswitch.com
-- Brian West | Co-founder and Developer Need Commercial support? email sales@freeswitch.com FreeSWITCH Solutions | 17345 Civic Drive #2531 Brookfield, WI 53045 <https://maps.google.com/?q=17345+Civic+Drive+%232531+Brookfield,+WI+53045&entry=gmail&source=g> Email: brian@freeswitch.com Mobile: 918-424-9378 Website: https://www.FreeSWITCH.com <https://www.freeswitch.com/> [image: https://www.facebook.com/signalwireinc?src=email] <https://www.facebook.com/freeswitch> [image: https://twitter.com/freeswitch] <https://twitter.com/freeswitch>
Hi Brian, Are you referring to switch_rtp_add_dtls() function? To my understanding, the ifdef is only activated for openssl version < 1.1.0 [1]. The `want_DTLSv1_2` is not taken into account for newer versions, so freeswitch may potentially use dtls version lower than 1.2. If that sounds correct, I can make a PR with SSL_CTX_set_min_proto_version() call if the `want_DTLSv1_2 flag is set for openssl version >= 1.1.0. [1] https://github.com/signalwire/freeswitch/blob/v1.10.3/src/switch_rtp.c#L3762 Best Regards, -- Valli A. Vallimamod SIP Solutions vma@sip.solutions linkedin.com/in/vallimamod .
On 19 May 2020, at 14:17, Brian West <brian@freeswitch.com> wrote:
It's already there, unless your version of OpenSSL doesn't have DTLS v1.2, Its wrapped in an ifdef HAVE_OPENSSL_DTLSv1_2_method
/b
On Tue, May 19, 2020 at 4:56 AM Valli A. Vallimamod <vma@vallimamod.org> wrote: Hi,
As you look familiar with the source code, you may add
SSL_CTX_set_min_proto_version(dtls->ssl_ctx, DTLS1_2_VERSION);
as a quick hack in switch_rtp.c around where DTLS_server_method() / DTLS_client_method() are called.
But it looks like a bug, you should create an issue on github.
Best Regards, -- Valli A. Vallimamod SIP Solutions vma@sip.solutions linkedin.com/in/vallimamod .
On 12 May 2020, at 19:43, François-Xavier Geneste <fx.geneste@telemaque.fr> wrote:
Hello guys,
I'm facing a big trouble for several hours ago and need help.... I'm using Freeswitch v1.10.2 with webRTC successfully installed and running. On the user/webphone side, I'm using Chrome 81.0.4044.138. Incoming and outgoing calls works fine with my webphone stack on my browsers (Firefox, Chrome). No warnings or errors at both sides.
But when I do the following scenario with a webphone that can manage several calls at the same time (multi-line feature), it does not work :
• make a first call routed to a webrtc extension, answer it and keep it connected • make a second call routed to the same extension, do not answer and keep the first call connected • make a third call routed to the same extension and hold the first line to accept this new call=> when I try to answer this 3rd call, the call is always dropped After digging into logs, and packets captured with wireshark, I found that when the freeswitch try to exchange with the browser to negociate SRTP flow for the 3rd call, it use DTLS v1.0 protocol (instead of v1.2) :
<lnancehjiedpjici.png>
Unfortunately, support for DTLS v1.0 seems to have been dropped on my webphone/browser side and the freeswitch fail on last DTLS exchange with this logs :
[INFO] switch_rtp.c:3736 Activate RTP/RTCP audio DTLS client [INFO] switch_rtp.c:3903 Changing audio DTLS state from OFF to HANDSHAKE [...] [ERR] switch_rtp.c:3266 audio Handshake failure 1. This may happen when you use legacy DTLS v1.0 (legacyDTLS channel var is set) but endpoint requires DTLS v1.2.
On freeswitch side, I found only one option linked to the DTLS version (legacyDTLS, as written in logs) which I never set in my config. I checked my open ssl version on the freeswitch server (1.1.1d).
The thing that is disturbing to me is that if I hold the first call and answer the second call, it works well. The issue occurs only for the third call and after a missed/refused call while still connected with first call in parallel.
Digging into freeswitch source, I found that it seems to use version-flexible DTLS methods of openssl (DTLS_server_method() and DTLS_client_method()) and I cannot see how to quicly and simply always force DTLS v1.2 ?
Have any of you ever had this kind of problem or know how to solve it ?
Regards,
FX
_________________________________________________________________________
The FreeSWITCH project is sponsored by SignalWire https://signalwire.com Enhance your FreeSWITCH install with disruptive priced SMS and PSTN services. Build your next product on our scalable cloud platform.
Join our online community to chat in real time https://signalwire.community
Professional FreeSWITCH Services sales@freeswitch.com https://freeswitch.com
Official FreeSWITCH Sites https://freeswitch.com/oss https://freeswitch.org/confluence https://cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users https://freeswitch.com
_________________________________________________________________________
The FreeSWITCH project is sponsored by SignalWire https://signalwire.com Enhance your FreeSWITCH install with disruptive priced SMS and PSTN services. Build your next product on our scalable cloud platform.
Join our online community to chat in real time https://signalwire.community
Professional FreeSWITCH Services sales@freeswitch.com https://freeswitch.com
Official FreeSWITCH Sites https://freeswitch.com/oss https://freeswitch.org/confluence https://cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users https://freeswitch.com
--
Brian West | Co-founder and Developer Need Commercial support? email sales@freeswitch.com FreeSWITCH Solutions | 17345 Civic Drive #2531 Brookfield, WI 53045 Email: brian@freeswitch.com Mobile: 918-424-9378 Website: https://www.FreeSWITCH.com
_________________________________________________________________________
The FreeSWITCH project is sponsored by SignalWire https://signalwire.com Enhance your FreeSWITCH install with disruptive priced SMS and PSTN services. Build your next product on our scalable cloud platform.
Join our online community to chat in real time https://signalwire.community
Professional FreeSWITCH Services sales@freeswitch.com https://freeswitch.com
Official FreeSWITCH Sites https://freeswitch.com/oss https://freeswitch.org/confluence https://cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users https://freeswitch.com
Are you saying that HAVE_OPENSSL_DTLSv1_2_method is not true on openssl 1.1? #define HAVE_OPENSSL_DTLSv1_2_method 1 on my box with openssl 1.1.1 If someone can point me to where this bug supposedly is, please provide info here. It should default the dtls 1.2 when built against any openssl that supports it, unless explicitly overridden.
On May 19, 2020, at 11:35 AM, Valli A. Vallimamod <vma@vallimamod.org> wrote:
Hi Brian,
Are you referring to switch_rtp_add_dtls() function? To my understanding, the ifdef is only activated for openssl version < 1.1.0 [1]. The `want_DTLSv1_2` is not taken into account for newer versions, so freeswitch may potentially use dtls version lower than 1.2.
If that sounds correct, I can make a PR with SSL_CTX_set_min_proto_version() call if the `want_DTLSv1_2 flag is set for openssl version >= 1.1.0.
[1] https://github.com/signalwire/freeswitch/blob/v1.10.3/src/switch_rtp.c#L3762
Best Regards, -- Valli A. Vallimamod SIP Solutions vma@sip.solutions linkedin.com/in/vallimamod .
On 19 May 2020, at 14:17, Brian West <brian@freeswitch.com> wrote:
It's already there, unless your version of OpenSSL doesn't have DTLS v1.2, Its wrapped in an ifdef HAVE_OPENSSL_DTLSv1_2_method
/b
On Tue, May 19, 2020 at 4:56 AM Valli A. Vallimamod <vma@vallimamod.org> wrote: Hi,
As you look familiar with the source code, you may add
SSL_CTX_set_min_proto_version(dtls->ssl_ctx, DTLS1_2_VERSION);
as a quick hack in switch_rtp.c around where DTLS_server_method() / DTLS_client_method() are called.
But it looks like a bug, you should create an issue on github.
.
On 12 May 2020, at 19:43, François-Xavier Geneste <fx.geneste@telemaque.fr> wrote:
Hello guys,
I'm facing a big trouble for several hours ago and need help.... I'm using Freeswitch v1.10.2 with webRTC successfully installed and running. On the user/webphone side, I'm using Chrome 81.0.4044.138. Incoming and outgoing calls works fine with my webphone stack on my browsers (Firefox, Chrome). No warnings or errors at both sides.
But when I do the following scenario with a webphone that can manage several calls at the same time (multi-line feature), it does not work :
• make a first call routed to a webrtc extension, answer it and keep it connected • make a second call routed to the same extension, do not answer and keep the first call connected • make a third call routed to the same extension and hold the first line to accept this new call=> when I try to answer this 3rd call, the call is always dropped After digging into logs, and packets captured with wireshark, I found that when the freeswitch try to exchange with the browser to negociate SRTP flow for the 3rd call, it use DTLS v1.0 protocol (instead of v1.2) :
<lnancehjiedpjici.png>
Unfortunately, support for DTLS v1.0 seems to have been dropped on my webphone/browser side and the freeswitch fail on last DTLS exchange with this logs :
[INFO] switch_rtp.c:3736 Activate RTP/RTCP audio DTLS client [INFO] switch_rtp.c:3903 Changing audio DTLS state from OFF to HANDSHAKE [...] [ERR] switch_rtp.c:3266 audio Handshake failure 1. This may happen when you use legacy DTLS v1.0 (legacyDTLS channel var is set) but endpoint requires DTLS v1.2.
On freeswitch side, I found only one option linked to the DTLS version (legacyDTLS, as written in logs) which I never set in my config. I checked my open ssl version on the freeswitch server (1.1.1d).
The thing that is disturbing to me is that if I hold the first call and answer the second call, it works well. The issue occurs only for the third call and after a missed/refused call while still connected with first call in parallel.
Digging into freeswitch source, I found that it seems to use version-flexible DTLS methods of openssl (DTLS_server_method() and DTLS_client_method()) and I cannot see how to quicly and simply always force DTLS v1.2 ?
Have any of you ever had this kind of problem or know how to solve it ?
Hi, I have created the following PR to make my explanation clearer: https://github.com/signalwire/freeswitch/pull/646 For me, the issue is not with `HAVE_OPENSSL_DTLSv1_2_method` but with the new `DTLS_server_method()` and `DTLS_client_method()` functions which support both dtls1.0 and dtls1.2[1]. My proposal is to limit to dtls1.2 with a call to `SSL_CTX_set_min_proto_version()`[2] as the version specific functions (DTLSv1_2_server_method() and DTLSv1_2_client_method()) are deprecated in openssl 1.1.1. [1] https://www.openssl.org/docs/man1.1.1/man3/DTLS_server_method.html [2] https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_min_proto_version.htm... Best Regards, -- Valli A. Vallimamod SIP Solutions vma@sip.solutions linkedin.com/in/vallimamod .
On 19 May 2020, at 20:38, Mike Jerris <mike@freeswitch.org> wrote:
Are you saying that HAVE_OPENSSL_DTLSv1_2_method is not true on openssl 1.1? #define HAVE_OPENSSL_DTLSv1_2_method 1 on my box with openssl 1.1.1
If someone can point me to where this bug supposedly is, please provide info here. It should default the dtls 1.2 when built against any openssl that supports it, unless explicitly overridden.
On May 19, 2020, at 11:35 AM, Valli A. Vallimamod <vma@vallimamod.org> wrote:
Hi Brian,
Are you referring to switch_rtp_add_dtls() function? To my understanding, the ifdef is only activated for openssl version < 1.1.0 [1]. The `want_DTLSv1_2` is not taken into account for newer versions, so freeswitch may potentially use dtls version lower than 1.2.
If that sounds correct, I can make a PR with SSL_CTX_set_min_proto_version() call if the `want_DTLSv1_2 flag is set for openssl version >= 1.1.0.
[1] https://github.com/signalwire/freeswitch/blob/v1.10.3/src/switch_rtp.c#L3762
Best Regards, -- Valli A. Vallimamod SIP Solutions vma@sip.solutions linkedin.com/in/vallimamod .
On 19 May 2020, at 14:17, Brian West <brian@freeswitch.com> wrote:
It's already there, unless your version of OpenSSL doesn't have DTLS v1.2, Its wrapped in an ifdef HAVE_OPENSSL_DTLSv1_2_method
/b
On Tue, May 19, 2020 at 4:56 AM Valli A. Vallimamod <vma@vallimamod.org> wrote: Hi,
As you look familiar with the source code, you may add
SSL_CTX_set_min_proto_version(dtls->ssl_ctx, DTLS1_2_VERSION);
as a quick hack in switch_rtp.c around where DTLS_server_method() / DTLS_client_method() are called.
But it looks like a bug, you should create an issue on github.
.
On 12 May 2020, at 19:43, François-Xavier Geneste <fx.geneste@telemaque.fr> wrote:
Hello guys,
I'm facing a big trouble for several hours ago and need help.... I'm using Freeswitch v1.10.2 with webRTC successfully installed and running. On the user/webphone side, I'm using Chrome 81.0.4044.138. Incoming and outgoing calls works fine with my webphone stack on my browsers (Firefox, Chrome). No warnings or errors at both sides.
But when I do the following scenario with a webphone that can manage several calls at the same time (multi-line feature), it does not work :
• make a first call routed to a webrtc extension, answer it and keep it connected • make a second call routed to the same extension, do not answer and keep the first call connected • make a third call routed to the same extension and hold the first line to accept this new call=> when I try to answer this 3rd call, the call is always dropped After digging into logs, and packets captured with wireshark, I found that when the freeswitch try to exchange with the browser to negociate SRTP flow for the 3rd call, it use DTLS v1.0 protocol (instead of v1.2) :
<lnancehjiedpjici.png>
Unfortunately, support for DTLS v1.0 seems to have been dropped on my webphone/browser side and the freeswitch fail on last DTLS exchange with this logs :
[INFO] switch_rtp.c:3736 Activate RTP/RTCP audio DTLS client [INFO] switch_rtp.c:3903 Changing audio DTLS state from OFF to HANDSHAKE [...] [ERR] switch_rtp.c:3266 audio Handshake failure 1. This may happen when you use legacy DTLS v1.0 (legacyDTLS channel var is set) but endpoint requires DTLS v1.2.
On freeswitch side, I found only one option linked to the DTLS version (legacyDTLS, as written in logs) which I never set in my config. I checked my open ssl version on the freeswitch server (1.1.1d).
The thing that is disturbing to me is that if I hold the first call and answer the second call, it works well. The issue occurs only for the third call and after a missed/refused call while still connected with first call in parallel.
Digging into freeswitch source, I found that it seems to use version-flexible DTLS methods of openssl (DTLS_server_method() and DTLS_client_method()) and I cannot see how to quicly and simply always force DTLS v1.2 ?
Have any of you ever had this kind of problem or know how to solve it ?
_________________________________________________________________________
The FreeSWITCH project is sponsored by SignalWire https://signalwire.com Enhance your FreeSWITCH install with disruptive priced SMS and PSTN services. Build your next product on our scalable cloud platform.
Join our online community to chat in real time https://signalwire.community
Professional FreeSWITCH Services sales@freeswitch.com https://freeswitch.com
Official FreeSWITCH Sites https://freeswitch.com/oss https://freeswitch.org/confluence https://cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users https://freeswitch.com
participants (4)
-
Brian West
-
François-Xavier Geneste
-
Mike Jerris
-
Valli A. Vallimamod