We’re trying to set up an Asterisk server with SIP-over-TLS and SRTP capabilities, and after using AsteriskNOW! for a more standard (UDP/RTP) setup, we decided on the FreePBX distro, as it seemed to meet our needs. However, our (apparently correctly) configured FreePBX 126.96.36.199 is being unstable in maintaining TLS connections.
Our setup adds the following configuration lines under SIP settings, using the “Other SIP settings” list:
tlsenable = yes tlsbindaddr = 0.0.0.0 tlscertfile = /etc/asterisk/keys/asterisk.pem tlscafile = /etc/asterisk/keys/ca.crt tlsclientmethod = tlsv1
From various tutorials found around the Internet, these were understood to be sufficient for SIP/TLS operation, and setting up the same configuration in AsteriskNOW! does result in reliable, securely-signalled communications. However, AsteriskNOW! does not support SRTP, which FreePBX does.
Our extensions, configured via the FreePBX web interface, look like this:
 deny=0.0.0.0/0.0.0.0 secret=[ellided] dtmfmode=rfc2833 canreinvite=no context=from-internal host=dynamic trustrpid=yes sendrpid=no type=friend nat=yes port=5060 qualify=yes qualifyfreq=60 transport=tls avpf=no icesupport=no encryption=no callgroup= pickupgroup= dial=SIP/2000 permit=0.0.0.0/0.0.0.0 callerid=2000 <2000> callcounter=yes faxdetect=no
As you will have noticed, the vast majority of settings are just left at their default state.
Upon initial registration, the client appears fully functional and can be called from other peers until the first qualify period expires, at which point the Asterisk server considers the client to be not responding. Upon the first session timer expiry, the client attempts to re-register and fails, timing out.
Here’s an asterisk remote console session displaying all interesting messages (with debug 9): http://pastie.org/private/u0zlyct8bniperlhiuffg
A Wireshark packet capture of the client side of a similar subsequent session is available on request, but being TLS-encrypted would probably not be terribly illuminating. For what it’s worth, all packets sent by the client were ACKed, even after the apparent re-registration timeout.
My most immediate question is: how do I get more information about what’s happening? There doesn’t seem to be any logical reason for the client to be getting lost from the server, and in a similar setup on AsteriskNOW!, it doesn’t – the only difference is the non-working FreePBX setup has SRTP available (but not enabled). This should not logically make any difference, so I’m stuck for the moment.
As an example of what we’ve attempted:
Changing the extension settings to avoid doing the qualify:
…did absolutely nothing but delay the moment of failure to whenever the client would attempt to re-register after a session timer expiry.
in the SIP settings didn’t help, either.
Flipping the NAT settings on the extension:
made the error manifest on initial register, which makes less than zero sense given we’re in a LAN environment and the advertised registration address is perfectly reachable from the server side.
If anyone has any ideas, I’d love to hear them.