Hello,
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 2.11.0.11 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 = tlsv1From 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:
[2000]
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=noAs 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:
qualify=no
qualifyfreq=0…did absolutely nothing but delay the moment of failure to whenever the client would attempt to re-register after a session timer expiry.
session-timers=refusein the SIP settings didn’t help, either.
Flipping the NAT settings on the extension:
nat=nomade 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.
Best regards,
Radu Curca.