|
受大环境影响，因效益不好，某客户裁撤了整个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
重启路由器，客户说是可以拨号了，又一次小小地兴奋了一下，没过几分钟，又来消息了，同一台路由器下，一个用户可以了，另外两个用户还是无法拨打电话，换个号码注册也是不行。 头疼欲裂，汗如雨下，无从下手…… 好在客户也有经验，把终端重置，重新配置，然后可以打电话了，此事暂时告一段落，换来我的一声长叹。 |
|
|
