概述
近几年,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的发展越来越好。
空空如常
求真得真