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”,看到如下配置:

这个配置的意思是,对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规则,让公网地址也可以通过可选规则。

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

 

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

修改 acl.conf.xml

修改 internal.xml

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

 

总结

Freeswitch和WEBRTC对接简单方便。

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

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

 

空空如常

求真得真

你可能感兴趣的:(freeswitch对接WEBRTC的一个candidate问题)