Asterisk启用TLS加密后通话出现Error 488故障排查请求

让我们一步步拆解你的问题，从日志和配置来看，Error 488（Not Acceptable Here）的核心是媒体流加密要求不匹配，具体原因和修复方案如下：

问题核心定位 #

你的用户201在sip.conf里配置了encryption=yes，这意味着Asterisk强制要求该用户的通话必须使用加密的RTP流（RTP/SAVP或RTP/SAVPF）。但从Blink发送的INVITE请求的SDP部分可以看到，客户端发送的是RTP/AVP（非加密媒体流），这和服务器的强制加密要求直接冲突，导致服务器拒绝通话并返回488错误。

另外，你提供的RTP日志警告也印证了这一点：

== Using SIP RTP CoS mark 5 [May 11 15:34:33] WARNING[21893][C-00000d0e]: chan_sip.c:10803 process_sdp: Rejecting secure audio stream without encryption details: audio 50026 RTP/SAVP 113 9 0 8 101

这个警告说明服务器收到了标记为加密的流，但缺少必要的加密细节（比如SDES密钥），进一步说明客户端的媒体加密配置没有生效。

具体修复步骤 #

1. 修正Blink客户端的媒体加密配置 #

你提到已经配置了强制SDES，但显然客户端没有正确启用媒体加密：

• 打开Blink的账号设置，除了确保SIP层启用TLS（端口5061），还要找到媒体加密选项，设置为强制启用（选择SDES，确保关联你生成的pem和ca.crt文件）
• 重新发起通话后，检查SDP是否会发送RTP/SAVP而非RTP/AVP，这是加密媒体流的关键标识。

2. 优化Asterisk的加密配置 #

你的sip.conf有几个可以调整的点：

• 将tlsclientmethod=tlsv1改为更现代的版本：tlsv1.2或tlsv1.3（TLSv1已经被淘汰，可能导致客户端和服务器的加密协商失败）
• 收紧tlscipher配置，避免使用过于宽泛的ALL，推荐使用安全的加密套件：

  tlscipher=ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
  

• 对于201用户，确保transport=tls和encryption=yes的配置一致，不需要额外添加UDP传输（除非你需要兼容非加密，但这里你要强制加密）

3. 验证NAT环境下的媒体流穿透 #

因为你的Asterisk部署在OVH的NAT服务器上，加密RTP流可能存在穿透问题：

• 确认OVH服务器的防火墙已经开放了默认的RTP端口范围（比如10000-20000，UDP协议）
• 确保Asterisk的nat=comedia配置正确，这个选项会自动处理NAT环境下的媒体流地址映射
• 开启Asterisk的调试日志，查看媒体流协商情况：

  asterisk -rx 'core set verbose 5'
  asterisk -rx 'rtp set debug on'
  

  发起通话后，通过tail -f /var/log/asterisk/full查看日志，确认RTP流的建立是否正常。

4. 证书有效性检查 #

虽然Wireshark显示SIP流量已加密，但还是要确认证书的配置没有问题：

• 检查证书文件的权限：确保Asterisk进程（一般是asterisk用户）能读取/etc/asterisk/keys/asterisk.pem和/etc/asterisk/keys/ca.crt，推荐设置权限为600
• 用OpenSSL验证TLS连接是否正常：

  openssl s_client -connect your-server-ip:5061
  

  查看输出是否有证书链错误或连接失败的提示。

测试流程 #

修复配置后，按以下步骤验证：

1. 重启Asterisk服务：asterisk -rx 'core restart now'
2. 在Blink中重新注册账号，发起加密通话
3. 查看Asterisk日志，确认没有RTP加密相关的警告，SIP交互过程正常

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