概述

近几年，WEBRTC的完善与成熟，使得网页上使用webrtc的应用越来越多。

Freeswitch是一个开源的软交换平台，可以直接支持webrtc的对接方式。

最近在测试fs和webrtc的对接中碰到一个问题。记录如下。

问题描述。

客户A，使用webrtc页面注册到fs，并发起呼叫到客户B。

A客户收到488 SIP响应码，结束呼叫。

环境

centos：CentOS release 7.0 (Final)或以上版本

freeswitch：v1.8.7

GCC：4.8.5

问题分析

SIP的488错误码一般是由于媒体协商问题造成的。

检查A/B路和fs的codec设置，并没有发现问题。

查看fs日志，发现挂断前的日志如下：

2022-03-24 14:50:48.663204 [DEBUG] switch_core_codec.c:111 sofia/internal/075512345678@webrtc Original read codec set to PCMA:8
2022-03-24 14:50:48.663204 [DEBUG] switch_core_media.c:3481 Save audio Candidate cid: 1 proto: udp type: host addr: 192.167.10.207:55231
2022-03-24 14:50:48.663204 [DEBUG] switch_core_media.c:3523 Searching for rtp candidate.
2022-03-24 14:50:48.663204 [DEBUG] switch_core_media.c:3523 Searching for rtcp candidate.
2022-03-24 14:50:48.663204 [DEBUG] switch_core_media.c:3567 sofia/internal/075512345678@webrtc no suitable candidates found.
...
a=candidate:3284465256 1 udp 2122260223 192.167.10.207 55231 typ host generation 0 network-id 1
a=candidate:2370243224 1 tcp 1518280447 192.167.10.207 9 typ host tcptype active generation 0 network-id 1
...
2022-03-24 14:50:48.663204 [NOTICE] switch_channel.c:3515 Hangup sofia/internal/075512345678@webrtc [CS_EXECUTE] [INCOMPATIBLE_DESTINATION]
2022-03-24 14:50:48.663204 [DEBUG] switch_ivr_originate.c:3848 Originate Resulted in Error Cause: 88 [INCOMPATIBLE_DESTINATION]

从日志中，可以看到在媒体协商的过程，有一个“no suitable candidates found”的信息。意思是webrtc中的ice框架没有找到合适的可选媒体地址。

同时，SDP中又有“a=candidate: udp 192.167.10.207 55231”的信息。

日志看起来比较奇怪，明明打印出来的有candidate信息，为什么又说找不到合适的candidate。

我们尝试百度了一下“192.167.10.207”这个地址，居然是属于意大利的IP，是一个公网地址。

经过和客户沟通，客户侧反馈信息是“192.167.10.207”是公司的内网地址。。。网管是个人才。

打开conf/sip_profile/internal.xml配置文件，查找“candidate”，看到如下配置：

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

这个配置的意思是，对ice框架中candidate可选地址设置acl规则，对不符合rfc1918规范的IP地址进行拦截。

Rfc1918规定的地址段如下，一般情况下，内网地址都要按照这3个网段来配置：

10.0.0.0 - 10.255.255.255 (10/8 prefix)
172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
192.168.0.0 - 192.168.255.255 (192.168/16 prefix)

问题就出在这里，fs对candidate设置了acl规则为rfc1918，客户配置的candicate又只有192.167的一个公网地址，造成了没有可选的媒体地址的问题。

解决方案

首先，客户修改本地地址是最简单的解决方式，只需要把192.167的内网地址修改为192.168网段即可。

但是回到fs服务器本身来看，如果有客户通过公网地址对接，即candidate无法获取到内网地址，还是会有上述的问题存在。

最终，从fs服务端出发的解决方案。

方案1，修改 internal.xml，增加candidate的acl规则，让公网地址也可以通过可选规则。

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

这样，无论客户的candidate中只有公网地址，还是只有私网地址，fs服务端都可以正常的建立媒体。

方案2，从acl自定义规则出发，设置candidate的acl规则为允许所有。

修改 acl.conf.xml

<list name="ice_candidate" default="allow">
</list>

修改 internal.xml

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

但是，该方案在实际测试过程中是有问题的，会造成公网和私网地址都无法通过candidate的acl规则，详细原因还未展开，留待后续跟踪。

总结

Freeswitch和WEBRTC对接简单方便。

对于客户来说，webrtc可以直接使用web浏览器发起呼叫，而不需要额外安装任何软件或插件，非常的友好。

希望fs和webrtc的发展越来越好。

空空如常

求真得真