Q & A
CDR Reports 沒有任何紀錄
檢查 MySQL 資料表
# MySQL Credentials
cat /etc/freepbx.conf
# Check the mysql
mysql -u freepbxuser -p asteriskcdrdb -e 'SELECT * FROM cdr ORDER BY calldate DESC LIMIT 4'
檢查 asterisk module
asterisk -rx "module show like odbc"
Module Description Use Count Status Support Level
cdr_adaptive_odbc.so Adaptive ODBC CDR backend 0 Running core
cdr_odbc.so ODBC CDR Backend 0 Running extended
cel_odbc.so ODBC CEL backend 0 Running core
func_odbc.so ODBC lookups 0 Running core
res_config_odbc.so Realtime ODBC configuration 0 Running core
res_odbc.so ODBC resource 6 Running core
res_odbc_transaction.so ODBC transaction resource 1 Running core
重啟服務出現以下錯誤
fwconsole stop
fwconsole start
[2022-06-03 10:38:42] WARNING[32144] res_odbc.c: res_odbc: Error SQLConnect=-1 errno=0 [unixODBC][Driver Manager]Can't open lib '/usr/lib/x86_64-linux-gnu/odbc/libmaodbc.so' : file not f
Solution:
#> locate libmaodbc.so
/usr/lib/i386-linux-gnu/odbc/libmaodbc.so
#> cp /etc/odbcinst.ini /etc/odbcinst.ini.orig
#> vi /etc/odbcinst.ini
# Change this line
Driver = /usr/lib/x86_64-linux-gnu/odbc/libmaodbc.so
重啟服務確認錯誤不再發生
fwconsole stop
fwconsole start
Can't send 10 type frames with SIP write
Frame type '10' is comfort noise (aka CNG) which Asterisk does not support.
However as of 13.18.0 this message will be silenced so you won’t see it anymore.
You can ignore it or disable CNG on all of your endpoints and ask the telecom providers as well to disable the CNG on your trunks.
FXO 不會正確地傳送 Answer 至 IP 端
當透過 Gateway 撥打外線時 (IP to PSTN),不管 PSTN 端是否接起電話,Gateway 總是傳送 Answer 至 IP 端。這個對於一般電話操作不會有影響,不過,若是要對通話進行計費時,就會造成很大問題。
原因及解法如下:
Polarity Reversal (極性反轉):電信商提供用戶交換機外線通話開始及結束之確認訊號,以利用戶電話 計費系統進行話務計費 (適用旅館業者)
The issue:
The VoIP gateway is sending an answer signal to the IP side, even when the call is not picked up on the PSTN side. This is not the expected behavior, as the gateway should only send an answer signal when the call is actually answered by the called party.
Possible causes:
- Improper FXO port configuration: The FXO port on the gateway might not be configured correctly, leading to the gateway sending an answer signal prematurely.
- PSTN line issues: There could be issues with the PSTN line, such as noise or electrical interference, that are causing the gateway to misinterpret the call status.
- Polarity Reversal Detection not functioning correctly: The Polarity Reversal Detection feature on the gateway might not be working as expected, which could be contributing to the issue.
Polarity Reversal Detection:
Polarity Reversal Detection is a feature used to detect when a call is answered or hung up on the PSTN side. When a call is answered, the polarity of the PSTN line reverses, and the gateway can detect this change to determine the call status. If the Polarity Reversal Detection is not functioning correctly, the gateway may not be able to accurately determine the call status.
How Polarity Reversal Detection works:
When a call is made from the IP side to the PSTN side, the gateway monitors the PSTN line for a polarity reversal. When the called party answers, the PSTN line polarity reverses, and the gateway detects this change. The gateway then sends an answer signal to the IP side, indicating that the call has been answered.
Troubleshooting steps:
- Verify FXO port configuration: Check the FXO port configuration on the gateway to ensure it is set up correctly. Consult the gateway's documentation or contact the manufacturer for guidance.
- Check PSTN line quality: Verify that the PSTN line is clean and free of noise or electrical interference. You can use a line tester or consult with the PSTN provider to troubleshoot line issues.
- Verify Polarity Reversal Detection settings: Ensure that the Polarity Reversal Detection feature is enabled and configured correctly on the gateway. Consult the gateway's documentation or contact the manufacturer for guidance.
- Monitor gateway logs: Check the gateway logs to see if there are any errors or anomalies related to the Polarity Reversal Detection feature.
- Test with a different PSTN line: If possible, test the VoIP gateway with a different PSTN line to isolate the issue.
By following these troubleshooting steps, you should be able to identify and resolve the issue causing the VoIP gateway to send an answer signal prematurely.
No Comments