find / -name freeswitch.xml，找到配置文件，看了一下，沒啥用，只是得到一個信息：欲知詳情，請看vars.xml，看完vars.xml，又得到一個信息：得繼續(xù)看Internal SIP Profile和External SIP Profile，很好，總算有點方向。該寫IP地址的地方，寫著auto，感覺有點問題啊，改為正確的IP地址，然后重啟FreeSwitch服務(wù)。

受大環(huán)境影響，因效益不好，某客戶裁撤了整個IT運維部門，我順理成章地接手了。

只是合同簽得簡單，要做的工作卻遠超范圍，負責(zé)人也是多年的朋友了，看在私人的友情上，就沒那么計較，直接幫著解決。

某云服務(wù)器遷移后，F(xiàn)reeSwitch終端無法撥打電話，一直顯示注冊中。

由于此次遷移并不涉及公網(wǎng)IP的變更，所以暫未考慮IP配置問題，但是所有終端都顯示注冊中，顯然是服務(wù)器問題了。

FreeSwitch是部署在Centos上，所以遠程登錄Centos，查詢FreeSwitch服務(wù)是否正常啟動了。

netstat -anp | grep freeswitch

發(fā)現(xiàn)FreeSwitch服務(wù)根本沒起來。

systemctl start freeswitch.service

然后再次執(zhí)行查詢命令：netstat -anp | grep freeswitch

FreeSwitch服務(wù)貌似起來了，并且占用了2260端口。

要求客戶終端測試，當(dāng)然還是不行。實不相瞞，本人第一次折騰FreeSwitch，所以當(dāng)時覺得服務(wù)起來，并且實測端口可被連接，就應(yīng)該好了，實際上，還差得遠。

繼續(xù)摸索：既然FreeSwitch服務(wù)起來了，那可能是數(shù)據(jù)庫的問題吧。

netstat -anp | grep mysql，果然，mysql服務(wù)沒起來。

systemctl start mysql.service，失敗，mysql起不來。

難道數(shù)據(jù)庫不是mysql？查看了一翻，果然是缺胳膊少腿，按理說，遷移過程中，不可能掉程序啊， systemctl list-units --type=service，列出所有服務(wù)，發(fā)現(xiàn)了 mariadb.service，而且沒有啟動。

趕緊systemctl start mariadb.service，然后systemctl status mariadb.service

MariaDB數(shù)據(jù)庫管理系統(tǒng)是MySQL的一個分支，所以，這時候netstat -anp | grep mysql

就能看到，mysql的3006端口起來了。

這時候，客戶回復(fù)，終端數(shù)據(jù)加載正常。

小小地興奮了一下，以為好了，但是客戶回復(fù)無法撥打電話。

一頭包，要知道，我這也是大姑娘上轎——頭一回啊，沒辦法既然答應(yīng)了客戶，就得繼續(xù)。

還是懷疑FreeSwitch服務(wù)的問題，畢竟，數(shù)據(jù)庫才剛剛起來，于是systemctl restart freeswitch.service，重啟服務(wù)，然后查次netstat -anp | grep freeswitch，果然，freeswitch的服務(wù)多出來好幾個，都是不同的端口。

再次讓客戶測試，回復(fù)是：可以打電話了。

總算松了口氣。

BUT，第二天，客戶又反饋，雖然能撥打電話，但是沒聲音的，等于沒搞定。

好吧，在食物中毒，劇烈嘔吐三次的情況下，堅持排查從沒遇到過的問題。

MariaDB數(shù)據(jù)庫服務(wù)正常，F(xiàn)reeSwitch服務(wù)正常，那就只能看看配置文件了。

可憐我手頭沒有任何資料，連配置文件在哪里都不知道。

客戶反饋，打電話終于有聲音了。

可惜，好景不長，沒過兩天，又有分校不能撥打電話了，有的分校又很正常，沒道理啊。

應(yīng)該不是服務(wù)器的問題，遠程登錄客戶的路由器，經(jīng)排查，SIP ALG未開啟，死馬當(dāng)活馬醫(yī)吧，啟用SIP ALG

重啟路由器，客戶說是可以撥號了，又一次小小地興奮了一下，沒過幾分鐘，又來消息了，同一臺路由器下，一個用戶可以了，另外兩個用戶還是無法撥打電話，換個號碼注冊也是不行。

頭疼欲裂，汗如雨下，無從下手……

好在客戶也有經(jīng)驗，把終端重置，重新配置，然后可以打電話了，此事暫時告一段落，換來我的一聲長嘆。