标签：24 192.167 fs candidate webrtc 地址 freeswitch WEBRTC
概述
近几年，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的发展越来越好。
空空如常
求真得真
标签：24,192.167,fs,candidate,webrtc,地址,freeswitch,WEBRTC 来源： https://www.cnblogs.com/qiuzhendezhen/p/16082866.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。