246好彩天天免费资枓大全 ∠  您当前所在位置:主页 > 246好彩天天免费资枓大全 >
FreeSWITCH使用经验:解决一个诡异的呼叫问题
发布日期:2020-05-22 15:20   来源:未知   阅读:

  问题描述太过简略,因此我们建议用户交纳一定的费用,我们进一步沟通后再决定具体价格,为了便于理解,我们管这个费用叫挂号费。

  不过,经不住客户再三沟通,最后简单问了一下客户使用的什么网关评估了一下可能出现的问题。

  其中有一个可能是迅时根本没挂断电话,可能是信号音检测问题,也可能是NAT穿越问题导致FreeSWITCH挂机后BYE消息没到达迅时因此电话未挂机,所以导致所有端口都被占用因此打不通电话。

  这也是为什么我们要收挂号费,我们需要一些时间做进一步检测以便确认问题。多数情况下,如果解决方法极其简单,我们也就不再多收费用了。或者告诉用户我们解决不了,去其它大医院看看。当然,如果我们认为还得进一步治疗则评估下一步治疗的价格。我们一直是这么做的。

  不过,这次不同,客户给了我们一些钱让我们保证解决问题。好吧,艺高人胆大,把单子接下了。

  1)客户用Windows版的FreeSWITCH。我们更熟悉Linux,一般都默认是Linux,在Linux上处理问题一般比Windows上快很多;

  2)客户的Windows只能用Teamviewer访问,而Linux如果SSH访问效率会高很多

  3)客户使用迅时MX8全FXS口网关,而我们之前一直以为是FXO口网关

  4)客户使用SIP中继对接到某运营商,但之前客户根本就没跟我们提到这个问题

  5)客户实际上是为客户的客户服务,客户也是用Teamviewer连接到客户的客户的Windows上,而客户的客户描述问题很不清

  但骑上虎了也不能轻易就下来,硬新头皮看看。客户一再声称摘机听忙音,但从我们检测后判断是客户拨号后才听忙音的。而且问题原因是SIP中继侧不通,跟迅时网关关系不大。

  客户FSX话机通过迅时呼到FreeSWITCH,FreeSWITCH再通过SIP中继呼出去,而问题就出现在SIP中继方面,FreeSWITCH刚启动时是好的,但过一阵再外呼是就回480,只有重启FreeSWITCH才能恢复正常状态。

  后来我们检查了一番,决定不重启FreeSWITCH,而是重新注册一下网关:

  sofia profile external register 010-NNNNNNNN

  其中010-NNNNNNNN是客户设置的网关的名字。本来是一串数字,保护隐私我们打了马赛克。

  客户说问题并没实际解决,而是出问题的周期缩短了。好像每次自动注册后打电话是好的,很短时间内就不好。

  从SIP概念上讲,4开头的响应码是客户端错误,应该在客户端修正然后重新发起呼叫可能就好了。

  我们已经在尝试修正了,比如改User Agent,开启Ping等。问题是这种错误要是有对端配合,可能很快就找到原因改好了,但是,如果对端不配合,你可能需要尝试一万种组合才可能解决问题。

  果然,我们所有的尝试都失败了。要知道,这种尝试是非常花费时间的。你改了,必须等待它再次出现,再改,再等死循环

  所以事实往往是很悲催的对端如果是大运营商的话,你能找到的所有人几乎都不懂技术;对端如果是小的“运营商”(姑且称之为是运营商吧)的话,往往也没有几个是懂技术的,他们往往只会告诉你一句话,人家别人用的都是好的

  说到别人,还真有。后来客户又告诉我们一个线索,人家迅时网关直接用这个SIP中继注册上去,打电话就没有问题!

  也算是个线索吧,抓包,对比,直到我们的包改的跟迅时的一模一样我们也是不能解决问题。

  而且我们发现迅时发的REGISTER消息Expire域为600,对方回的是60,但我们在FreeSWITCH里也写了600,对方回的就是1800。没头绪。

  直接让迅时注册这个SIP中继。FSX口的话机打电话时,先送到FreeSWITCH,FreeSWITCH再送到迅时,再通过这个中继出去。有点绕,但是这也算是一种解决方案吧。

  迅时跟FreeSWITCH对接可以简单的通过IP对接,即将呼叫送到FreeSWITCH的5080端口,不过,这样有点不安全不是。所以,我们需要FSX口发起的电话呼叫到达FreeSWITCH时,FreeSWITCH对迅时网关进行认证。

  1)在FreeSWITCH中设置ACL,允许ACL中指定的IP(即迅时网关的IP)呼叫5060端口。这种方式需要改ACL及Profile的一些配置,客户没采用这种方式。

  在ACL中添加迅时的IP。这样,迅时网关过来的呼叫就直接信任,不再发Challenge。但FreeSWITCH默认还是走public Dialplan,可以在internal.xml里设置将默认的 context = public 设成 context = default 以及任何其它值。

  2)在FreeSWITCH中添加跟SIP中继网关上一样的用户名和密码,当迅时来的呼叫到达FreeSWITCH 5060端口时发起Challenge,此时,由于迅时注册到远端的SIP中继上,因此会用远端的SIP中继提供的用户名和密码回应FreeSWITCH,即用户010NNNNNNNN和密码PPPPPPPP。

  因此,我们就在FreeSWITCH中添加了一个用户,用户名是010NNNNNNNN密码是PPPPPPPP。

  这样,迅时网关就能呼叫FreeSWITCH的5060端口并正确的认证(仅在呼叫INVITE时认证,不注册)。

  FXS x ROUTE IP 192.168.1.100 # 任何来自FSX的呼叫都路由到FreeSWITCH

  IP 1001 ROUTE FSX 1 # 来自FreeSWITCH的呼到,如果被叫号码是1001,则路由到第一个电线 ROUTE FSX 2 # 以此类推

  IP 010NNNNNNNN ROUTE IP 192.168.1.100:5080 #来自SIP中继的呼叫,如果呼入,则路由到FreeSWITCH,放IVR

  IP x ROUTE IP 1.2.3.4 # 其它任何号码都路由到SIP中继网关,以1.2.3.4为例

  以前,迅时网关是直接注册到FreeSWITCH上的,因此,一个回呼命令类似如下的样子:

  originate user/1001 &bridge(sofia/gateway/010-NNNNNNNN/)

  但经我们改动后,迅时不再向FreeSWITCH注册,因此没有了本地用户,所以,呼叫命令改成:

  originate sofia/gatewayxunshi/1001 &bridge(sofia/gateway/xunshi/)

  不要低估问题的复杂性,显然很多问题也可以分分钟解决,但不可否认,大部分问题都会有意外



Power by DedeCms