Is there any way to specify the full contact header in a UA profile that the SIP stack will use when formulating messages? Specifically, have it use "sips" instead of "sip" as the protocol scheme? I'm trying to establish an INVITE dialog between 2 FreeSWITCH servers using a client authenticated TLS handshake. To accomplish this, I've created 2 UA profiles on both servers - one to fulfill the role of the UAC (i.e. tls-uac.xml) and one to implement the UAS (i.e. tls-uas.xml). Here are the relevant parameters from both profiles: tls-uac.xml: <param name="sip-port" value="5081"/> <param name="tls" value="true"/> <param name="tls-only" value="true"/> <param name="tls-sip-port" value="5082"/> <param name="tls-cert-dir" value="$${base_dir}/conf/tls/uac"/> tls-uas.xml: <param name="sip-port" value="5081"/> <param name="tls" value="true"/> <param name="tls-only" value="true"/> <param name="tls-sip-port" value="5081"/> <param name="tls-cert-dir" value="$${base_dir}/conf/tls/uas"/> The problem already starts when "tls-uac" sends a non-secure SIP URI in the contact header of its initial INVITE request (i.e. sip:mod_sofia@10.191.210.150:5081). But the more immediate issue is that "tls-uas" also responds with a non-secure SIP URI in the contact header of its final response (i.e. sip:14086805675@10.191.210.151:5081;transport=udp). This causes "tls-uac" to send its ACK to the right port number (i.e. 5081) but on the wrong transport (i.e. UDP instead of TCP/TLS). I've seen in the FS documentation that there are ways to manipulate the contact header through the dial plan, but I'd really prefer not to do it this way. Any suggestions? Thanks JP