FreeSWITCH配置SRTP+TLS异常：呼叫时TLS中断且INVITE未加密

问题概述 #

已配置SRTP，可建立TLS会话，但呼叫时触发encrypted alert导致TLS会话终止，INVITE回退到TCP传输；拨号计划中设置bridge的transport=TLS时，提示TLS not supported by profile。

配置文件中的明显错误 #

先修复配置里的语法与重复定义问题，这是导致配置不生效的常见原因：

1. 引号语法错误：
   原配置中bind-params的引号不匹配，会导致参数解析失败：

   <!-- 错误写法 -->
   <param name='bind-params&quot; value=&quot;tls&quot;/>>
   <!-- 修正后 -->
   <param name="bind-params" value="tls"/>
   

2. 重复定义tls-version：
   配置中先后设置了固定值tlsv1和全局变量$${sip_tls_version}，后者会覆盖前者，建议保留全局变量以保持配置一致性：

   <!-- 移除重复的固定值定义 -->
   <!-- <param name='tls-version' value='tlsv1'/> -->
   <param name="tls-version" value="$${sip_tls_version}"/>
   

3. 端口冲突风险：
   ws-binding使用了标准SIP TLS端口5061，建议改为WS专属端口（如5062），避免与TLS端口冲突：

   <param name="ws-binding" value="XX.XX.XX.XX:5062"/>
   

针对核心问题的修复方案 #

1. 解决TLS not supported by profile错误 #

• 确认SIP Profile的TLS已启用：检查$${internal_ssl_enable}全局变量是否设为true，确保tls参数生效：

  <param name="tls" value="true"/> <!-- 或保留全局变量$${internal_ssl_enable}，确保其值为true -->
  

• 拨号计划中bridge命令需明确指定启用TLS的Profile，例如：

  <action application="bridge" data="sofia/internal/user@example.com?transport=tls"/>
  

• 确保Profile的tls-only参数设为true，强制所有SIP流量走TLS，禁止回退到TCP：

  <param name="tls-only" value="true"/>
  

2. 排查encrypted alert导致TLS会话终止 #

• 更新TLS版本与加密套件：tlsv1安全性低且可能与对端不兼容，建议将全局变量sip_tls_version设为tls1.2或tls1.3，并使用兼容的加密套件：

  <param name="tls-ciphers" value="ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256"/>
  

• 验证证书完整性：虽然呼叫前TLS正常，但呼叫时可能需要完整的证书链，检查/usr/local/freeswitch/conf下的证书文件（cert.pem、key.pem、chain.pem）是否存在，且FreeSWITCH进程拥有读取权限：

  chown -R freeswitch:freeswitch /usr/local/freeswitch/conf/*.pem
  chmod 600 /usr/local/freeswitch/conf/*.pem
  

• 开启详细调试日志：通过fs_cli开启TLS调试日志，定位encrypted alert的具体原因：

  fs_cli -x "loglevel 7"
  

  查看日志中TLS握手阶段的错误信息，比如证书验证失败、加密套件不匹配等。

3. 确保SRTP与TLS协同工作 #

确认rtp_secure_media参数配置正确，强制使用SRTP：

<param name='rtp_secure_media' value='mandatory: AES_CM_128_HMAC_SHA1_80'/>

同时确保对端支持相同的SRTP加密套件，避免协商失败导致呼叫异常。

内容的提问来源于stack exchange，提问作者Aina