受大环境影响,因效益不好,某客户裁撤了整个IT运维部门,我顺理成章地接手了。
只是合同签得简单,要做的工作却远超范围,负责人也是多年的朋友了,看在私人的友情上,就没那么计较,直接帮着解决。
某云服务器迁移后,FreeSwitch终端无法拨打电话,一直显示注册中。
由于此次迁移并不涉及公网IP的变更,所以暂未考虑IP配置问题,但是所有终端都显示注册中,显然是服务器问题了。
FreeSwitch是部署在Centos上,所以远程登录Centos,查询FreeSwitch服务是否正常启动了。
netstat -anp | grep freeswitch
发现FreeSwitch服务根本没起来。
systemctl start freeswitch.service
然后再次执行查询命令:netstat -anp | grep freeswitch
FreeSwitch服务貌似起来了,并且占用了2260端口。
要求客户终端测试,当然还是不行。实不相瞒,本人第一次折腾FreeSwitch,所以当时觉得服务起来,并且实测端口可被连接,就应该好了,实际上,还差得远。
继续摸索:既然FreeSwitch服务起来了,那可能是数据库的问题吧。
netstat -anp | grep mysql,果然,mysql服务没起来。
systemctl start mysql.service,失败,mysql起不来。
难道数据库不是mysql?查看了一翻,果然是缺胳膊少腿,按理说,迁移过程中,不可能掉程序啊, systemctl list-units --type=service,列出所有服务,发现了 mariadb.service,而且没有启动。
赶紧systemctl start mariadb.service,然后systemctl status mariadb.service
MariaDB数据库管理系统是MySQL的一个分支,所以,这时候netstat -anp | grep mysql
就能看到,mysql的3006端口起来了。
这时候,客户回复,终端数据加载正常。
小小地兴奋了一下,以为好了,但是客户回复无法拨打电话。
一头包,要知道,我这也是大姑娘上轿——头一回啊,没办法既然答应了客户,就得继续。
还是怀疑FreeSwitch服务的问题,毕竟,数据库才刚刚起来,于是systemctl restart freeswitch.service,重启服务,然后查次netstat -anp | grep freeswitch,果然,freeswitch的服务多出来好几个,都是不同的端口。
再次让客户测试,回复是:可以打电话了。
总算松了口气。
BUT,第二天,客户又反馈,虽然能拨打电话,但是没声音的,等于没搞定。
好吧,在食物中毒,剧烈呕吐三次的情况下,坚持排查从没遇到过的问题。
MariaDB数据库服务正常,FreeSwitch服务正常,那就只能看看配置文件了。
可怜我手头没有任何资料,连配置文件在哪里都不知道。
find / -name freeswitch.xml,找到配置文件,看了一下,没啥用,只是得到一个信息:欲知详情,请看vars.xml,看完vars.xml,又得到一个信息:得继续看Internal SIP Profile和External SIP Profile,很好,总算有点方向。
该写IP地址的地方,写着auto,感觉有点问题啊,改为正确的IP地址,然后重启FreeSwitch服务。
客户反馈,打电话终于有声音了。
可惜,好景不长,没过两天,又有分校不能拨打电话了,有的分校又很正常,没道理啊。
应该不是服务器的问题,远程登录客户的路由器,经排查,SIP ALG未开启,死马当活马医吧,启用SIP ALG
重启路由器,客户说是可以拨号了,又一次小小地兴奋了一下,没过几分钟,又来消息了,同一台路由器下,一个用户可以了,另外两个用户还是无法拨打电话,换个号码注册也是不行。
头疼欲裂,汗如雨下,无从下手……
好在客户也有经验,把终端重置,重新配置,然后可以打电话了,此事暂时告一段落,换来我的一声长叹。
本文分享自 IT狂人日志58446291 微信公众号,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。
本文参与 腾讯云自媒体同步曝光计划 ,欢迎热爱写作的你一起参与!