freeswitch对接WEBRTC的一个candidate问题
概述
近几年，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的发展越来越好。
空空如常
求真得真
