WebRTC通话INCOMPATIBLE_DESTINATION问题排查、verto与STUN协议

一个功能完整的WebRTC应用需要：

• 使用GetUserMedia API 控制麦克风和摄像头
• 使用一种会话协议和可能的外部辅助服务器定位对方端点并建立会话
• 使用ICE（和STUN和TURN）确定网络路径
• 使用RTCPeerConnection 传输音/视频媒体流

 

 

问题记录：

脱机环境，没有连接公网。网页电话建立后，立即挂断。SIP报错信息：

488 Not Acceptable Here (INCOMPATIBLE_DESTINATION) 

 

排查过程：

首先想到了是WebRTC需要证书，因为https和wss是WebRTC所需要的，浏览器对此有限制。于是自签证书，在nginx上以ssl对证书进行认证。不过 没有解决问题。

其次，根据SIP信令状态码，推测原因有二，首先是编码不兼容协商失败，其次是地址问题，因为WebRTC使用STUN处理防火墙穿透和NAT地址穿透。因此为了对应这个问题 在FreeSWITCH中追加IP地址是本机IP的 acl条目 ，这个条目在conf/sip_profiles/internal.xml中加应该也可以 ：

 

 配置文件路径：conf/autoload_configs/verto.conf.xml ，追加内容：

<param name="apply-candidate-acl" value="192.168.71.137"/>

 

在此问题出现之前，已经加过的acl有如下：

 

               <param name="apply-candidate-acl" value="localnet.auto"/>                                                     

               <param name="apply-candidate-acl" value="wan_v4.auto"/>                                                       

               <param name="apply-candidate-acl" value="rfc1918.auto"/>                                                      

               <param name="apply-candidate-acl" value="any_v4.auto"/>

 

 

遗憾的是，仍然会有488 的问题。

 

随后也尝试了从STUN的角度解决问题。比如在本机搭建TURN服务，并且从WebRTC的javascript代码中改iceServers内容。主要是对STUN不太熟悉，所以也不清楚是不是配置成功。最终也没有解决488的问题。搁置。

 

那么，回到问题本身，会不会是编码原因？

freeswitch对webrtc通话提供了opus编码，在生产环境、测试环境已经验证可以使用。脱机环境使用了相同的系统以及配置，似乎这个是最不可能的原因。

为了验证问题，将fs提供的编码改为PCMA，没想到的是通话媒体建立成功，并且应答以后没有任何问题。

 

那真正的原因是什么，恐怕不是编码不支持这么简单。

为何在无公网环境，opus不能使用？

 

第二天，将公司定制化的javascript包放到虚拟机的demo目录，替换官方demo的verto-min.js包，使用软电话呼叫webrtc坐席，使用成功，媒体建立成功。

到此，排除了fs和前端webrtc代码问题。

 

说明下环境信息：

freeswitch地址： 172.16.10.40

浏览器地址：172. 16.10.171

 

在verto中 acl追加了一个项目，注释掉其他所有的acl条目。

 

<param name="apply-candidate-acl" value="172.16.10.40"/>  

 

再打电话， 这时webrtc通话仍然报错，错误码不同，SIP状态码是480，前端显示“CODEC ERROR”，freeswitch日志中显示“ Temporarily unavailable ” ，再 结合在freeswitch的日志中，有一行关键信息：

 

5d44774b-5331-455d-ac7e-18f8547c8b70 2020-05-20 15:15:44.503732 [DEBUG] switch_core_media.c:3567 verto.rtc/a0e5445a-d820-f2e0-ebe5-3d117ea12c64 no suitable candidates found.

据此推断，这个candidate不光是指服务端，也应用在webrtc浏览器一端，于时修改acl条目：

<param name="apply-candidate-acl" value="172.16.10.0/24"/>

 

修改后重新加载verto模块，再次呼叫。成功，媒体建立完成。前端出现“display”消息。

总结一下， poc环境，单个物理机上部署了多种服务，前端后端以及AI服务。AI服务使用了防火墙，在docker的多个虚拟网卡进行转发。可能会影响了STUN服务的作用。因此webrtc找建立媒体通道失败。

 

PS：

在本地虚拟机环境上，搭建了与poc相同的环境，前端使用fs官方发布的demo代码、公司定制化的verto.js包。