Earlier today on trunk there was a fix committed so that if you have had an issue getting registrations to work over TLS/TCP try again as it may just work now without any config changes. In addition there is a set of patches to expose some additional TLS options. The patches are at: http://jira.freeswitch.org/browse/FS-3071 the first patch (sofia_tls_extra_options.patch) is the main one, the other two are only needed if you want to use private keys that are passworded, note the upstream patch needs to be applied in the freeswitch/libs/sofia-sip. If you are using freeswitch to connect to a remote server securely it is highly advisable to be using the options in this patch. Right now freeswitch does no certificate validation which means you could easily be MITM defeating the encryption. The main config options for sip profiles are: tls-verify-policy - this is the important one, set to 'out' to ensure remote servers we connect to(gateways) have a valid certificate, set to 'in' to ensure any clients connecting to us have a valid certificate, and set to 'all' to validate both. tls-only - set to true and freeswitch will not even bind for un-encrypted registrations tls-no-verify-date - set to true to disable checking of the dates in certificates tls-verify-depth - max depth for validating a certificate and optionally with the extra two patches: tls-passphrase - set the passphrase for the private keys used NOTE: once you enable certificate validation you will want to ensure in your tls-cert-dir you have a cafile.pem which contains the entire certificate chain to validate connections. Most of the time this is going to just be the CA cert for the certificate issuer. Also you can optionally put an agent.pem in the cert-dir this is the key/cert that will be used for freeswitch when it connects out (its client certificate/key). It is not needed however if the remote side is not validating you. If you are running into problems try turning up the debug level by setting "sofia loglevel tport 9" it should give you more details about why things fail (as otherwise you may just see gateway timeout messages or something similar). Please test if you can! Also for those not using TLS /SSL right now and going over the internet you should try and switch to it if possible. There is very low overhead (using sslv23 you still have udp packets for the actual rtp stream and they are just 167 bytes vs 164 without encryption) to get started with it take a look at: http://wiki.freeswitch.org/wiki/SIP_TLS Note I would suggest sslv23 over tlsv1, sslv23 keeps the RTP stream as UDP which should mean least chance of a difference between no encryption and with encryption. The page does not take into account these new changes yet however. For a 30 second tutorial on getting started in linux: from the freeswitch bin dir on the server: ./gentls_cert setup -cn pbx.yourdomain.com -alt DNS:pbx.yourdomain.com -org pbx.yourdomain.com ./gentls_cert create -cn pbx.yourdomain.com -alt DNS:pbx.yourdomain.com -org pbx.yourdomain.com then make sure your freeswitch user owns the conf/ssl folder generated. Copy cafile.pem from it to any clients then set the following options in your profile config: <param name="tls" value="true"/> <param name="tls-bind-params" value="transport=tls"/> <param name="tls-version" value="sslv23"/> <param name="tls-verify-policy" value="none"/> and you should be able to have clients register securely( again see wiki page for more information). For freeswitch client: enable the above tls options, put the cafile.pem from the server in the conf/ssl folder, set: <param name="tls-verify-policy" value="out"/> and in the gateway: <param name="register-transport" value="tls" /> <param name="contact-params" value="tport=tcp"/> <param name="realm" value="sip.yourserver.com:5061" /> (or whatever the TLS port you are using is) ~Mitch