Hi,
The issue is persistent. I am curious to know if anyone else on the list is experiencing this. It doesn't seem to have been reported before.
Should I dedicate a profile to TLS use only?
I also posted a message on the list about receiving options packet with the wrong transport. Are these 2 issues connected? Here is a copy paste of my message:

My experience with FS and TLS has been rather mixed so far. It's been a little inconsistent in keeping NAT sessions up and users discoverable.
One thing I've noticed is that FS advertises the wrong information in option packets. The following is what I receive over my TLS session which is working on port 443.
1.2.3.4:443 -(SIP over TLS)-> 10.0.0.99:51132
OPTIONS sip:53178246@10.0.0.99:56494;transport=tls;received=5.6.7.8:51132 SIP/2.0
Via: SIP/2.0/TLS 1.2.3.4:443;branch=z9hG4bK6Kv171Q3U5rrD
Route: <sip:53178246@5.6.7.8:51132>;transport=tls
Max-Forwards: 70
From: <sip:mod_sofia@1.2.3.4:5060>;tag=Q6XDFHeUUrcHD
To: <sip:user@domain.com>
Call-ID: 0a052f23-34a8-4158-8c88-fd2a70ffb561_c2RhaSoOYBR6jfJe4ndLoTTKJMrO2gMv
CSeq: 71498568 OPTIONS
Contact: <sip:mod_sofia@1.2.3.4:5060>
User-Agent: FreeSWITCH
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer
Content-Length: 0

As you can see FS stamps the packet with a port 5060... No reference to port 443 with a transport=tls.

What shall be done?

On Feb 5, 2015, at 3:18 PM, Emrah <lists@kavun.ch> wrote:

Hi there,
This issue is happening all around with devices using TLS. It's not very frequent with softphones, but not inexistant.
Any pointers would be greatly appreciated. Do you have  best practice configs you'd like to share?

Thanks
On Jan 30, 2015, at 6:10 PM, Emrah <lists@kavun.ch> wrote:

Hi all,
I am facing a very frustrating issue. I often have to dial twice when using my Yealink phone with TLS because the first attempt times out.
The logs on the Yealink indicate that the first invite is successfully received, to which my FS sends a 100 trying and 407 proxy auth required. It is subsequently when my phone sends back the invite that the connection crashes with the following error:
SSL ERROR SYSCALL

Is this something common? Why does the SSL connection crashes when the phone attempts to send the second invite? My phone is behind NAT.

It is going to be a crazy expedition to collect the logs and Pastebin them, so I am tempting my luck on the list first to see if you have any pointers.

As a last piece, my Bria on my iPHone, among other clients, never had this issue. I did experience it from time to time with Blink on Mac OS X.

Any help appreciated.

Emrah