<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Michael and the list,<div class="">Without doing anything on the FS side, calls are going through fine today with both TLS and SDES in use on my clients.</div><div class=""><br class=""></div><div class="">When calls started failing, I had to disable SRTP on my clients to be able to be able to make calls again. TLS stayed on. I also disconnected a Polycom phone to switch it to a none TLS environment.</div><div class="">Today, one of the Yealink I had left unchanged (TLS + SRTP), is working fine again. I cannot get it to break, whereas a few hours prior it would crash the TLS session consistently for every single call.</div><div class=""><br class=""></div><div class="">Remember that FS gets the initial packets up to the ACK after the 407 Proxy Authentication Required is sent. It's the following invite that is never received, except if I disable SRTP. This made me conclude that it's a packet size / segmentation issue of my TCP packet.</div><div class=""><br class=""></div><div class="">Are you aware of any network layer control that could be causing this? Buffering on Linux in any way? Any concept of a TCP pool that could be getting full? Anything of that nature, that was flushed or emptied by the reduced number of clients calling using TLS + SRTP?</div><div class=""><br class=""></div><div class="">It's a long shot, but I thought I'd lay it here, see if it sparks something in your bright minds.</div><div class=""><br class=""></div><div class="">Thanks!</div><div class=""><div><blockquote type="cite" class=""><div class="">On Nov 9, 2016, at 8:28 PM, Emrah <<a href="mailto:lists@kavun.ch" class="">lists@kavun.ch</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">It's the "reliably" part that's tricky. <div class="">I'm using commercial certificates, so let me figure out how to replicate a similar environment. I'll email you the info once I have a setup, and you can circulate where needed.</div><div class=""><br class=""></div><div class="">Thanks for helping on this</div><div class=""><div class=""><blockquote type="cite" class=""><div class="">On Nov 9, 2016, at 4:25 PM, Michael Jerris <<a href="mailto:mike@jerris.com" class="">mike@jerris.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I need a recipie to reliably reproduce this so I can dig in the code. Is there a way you can put together an environment where this can be reproduced on demand?<div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Nov 9, 2016, at 3:39 AM, Emrah <<a href="mailto:lists@kavun.ch" class="">lists@kavun.ch</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">No Sir, the response packet to the 407 Proxy Authentication Required is never received. So the session then eventually gets abandoned by FS. On the client side, and this is generalized, the packet is sent, except the TLS session breaks.<div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Nov 8, 2016, at 11:41 PM, Michael Jerris <<a href="mailto:mike@jerris.com" class="">mike@jerris.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Can you confirm if the packet is shown in freeswitch tport_log?</span><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Nov 8, 2016, at 5:02 PM, Emrah <<a href="mailto:lists@kavun.ch" class="">lists@kavun.ch</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hello List,<div class="">Thanks to the help provided by Stanislav, I learned of issue #9113, <span class="" style="color: rgb(0, 105, 217); text-decoration: underline;"><a href="https://freeswitch.org/jira/si/jira.issueviews:issue-html/FS-9113/FS-9113.html" class="">https://freeswitch.org/jira/si/jira.issueviews:issue-html/FS-9113/FS-9113.html</a>, which seems to be related to the issues I have been experiencing with FreeSWITCH, TLS and failed call setups.</span></div><div class=""><span class="" style="color: rgb(0, 105, 217); text-decoration: underline;">Coincidentally, or not, the fix pushed on that issue was aligned with whole months where I did not experience any TLS issues. Calls were going through fine, until all of a sudden they started failing again. This is on 2 distinct servers running a load balanced FS setup, and using Yealink phones.</span></div><div class=""><span class="" style="color: rgb(0, 105, 217); text-decoration: underline;"><br class=""></span></div><div class=""><font color="#0069d9" class=""><u class="">To sum up, here is what is going on.</u></font></div><div class=""><font color="#0069d9" class=""><u class="">From the Yealink, calls with TLS work if I don't use SRTP.</u></font></div><div class=""><font color="#0069d9" class=""><u class="">From the Yealink, calls crash if I use TLS and SRTP.</u></font></div><div class="">From my laptop softphone, calls only crash sometimes if I use TLS and SRTP.</div><div class=""><br class=""></div><div class="">How can I debug the TLS session on the FreeSWITCH side to see what happens with the TLS thread? I don't mean packet capture.</div><div class=""><br class=""></div><div class="">I have a feeling that the packet size is too large and doesn't make it to the FS box intact after the 407 Proxy Required is received by the client.</div><div class=""><br class=""></div><div class="">Here is the log for the Yealink:</div><div class=""><a href="http://pastebin.com/smKP286x" class="">http://pastebin.com/smKP286x</a></div><div class=""><br class=""></div><div class="">Your lights would be so appreciated, I'm losing my mind over this.</div></div></div></blockquote></div></div><br class=""></div></blockquote></div></div></div></div></blockquote></div></div></div>_________________________________________________________________________<br class="">Professional FreeSWITCH Consulting Services: <br class=""><a href="mailto:consulting@freeswitch.org" class="">consulting@freeswitch.org</a><br class=""><a href="http://www.freeswitchsolutions.com" class="">http://www.freeswitchsolutions.com</a><br class=""><br class="">Official FreeSWITCH Sites<br class="">http://www.freeswitch.org<br class="">http://confluence.freeswitch.org<br class="">http://www.cluecon.com<br class=""><br class="">FreeSWITCH-users mailing list<br class="">FreeSWITCH-users@lists.freeswitch.org<br class="">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users<br class="">UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users<br class="">http://www.freeswitch.org</div></blockquote></div><br class=""></div></div></div></div></blockquote></div><br class=""></div></body></html>