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包。

WebRTC通话INCOMPATIBLE_DESTINATION问题排查、verto与STUN协议相关推荐

WebRTC通话原理
WebRTC通话原理目录媒体协商-音视频编解码网络协商 STUN TURN 媒体协商+网络协商数据的交换通道 WebRTC API 一对一通话 1. 媒体协商-音视频编解码比如: Peer- ...
WebRTC通话原理(六)
WebRTC通话原理-基本流程基本流程 WebRTC通话最典型的应用场景就是一对一音视频通话,如微信或QQ音视频聊天.通话的过程是比较复杂的,这里我们简化这个流程,把最主要的步骤提取出来,如图所示. ...
stun 协议 NAT穿透方式简介
STUN是RFC3489规定的一种NAT穿透方式,它采用辅助的方法探测NAT的IP和端口.毫无疑问的,它对穿越早期的NAT起了巨大的作用,并且还将继续在NAT穿透中占有一席之地. STUN的探测过程需 ...
mediasoup 源码分析（二十四）stun 协议分析
目录 stun介绍 stun 协议分析属性消息 stun介绍 stun 即:Session Traversal Utilities for NAT.用于NAT穿透的网络协议. 作用: stun协议主 ...
新型DDoS来袭 | 基于STUN协议的DDoS反射攻击分析
简介: 作为新型反射类型,目前仍存绕过防御可能性. 阿里云安全近期发现利用STUN(Session Traversal Utilities for NAT,NAT会话穿越应用程序)服务发起的DDoS反 ...
STUN协议简要介绍
参考:https://www.rfc-editor.org/rfc/rfc5766.html STUN/TURN https://www.rfc-editor.org/rfc/rfc5389.htm ...
WebRTC的ICE之Dtls/SSL/TLSv1.x协议详解
WebRTC的ICE之Dtls/SSL/TLSv1.x协议详解 WebRTC的ICE之Dtls/SSL/TLSv1.x协议详解 WebRTC的ICE之Dtls/SSL/TLSv1.x协议详解前言一 ...
STUN协议和常用NAT类型
文章目录 Nat的基本原理 Nat的优缺点 Nat的3种形态 1.静态NAT (一对一) 2.动态NAT (多对多) 3.端口多路复用(多对一,目前使用最多的) NATP类型的分类 (1)全锥型(Fu ...
构建 WebRTC 应用所需的后端服务 STUN, TURN
Build the backend services needed for a WebRTC app STUN, TURN, and signaling 机翻原文:Build the backend ...

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

488 Not Acceptable Here (INCOMPATIBLE_DESTINATION)

WebRTC通话INCOMPATIBLE_DESTINATION问题排查、verto与STUN协议相关推荐

最新文章

热门文章