Опять слетает кодировка при Русском Caller ID

[s.yu.lubin]

раз в сутки запускаю волшебную команду перезапуска mysql модуля
плюс волшебную команду конвертации cdr записей
всё ровно

Ответ на ваш вопрос, по другому никак, сам кучу времени потратил на решение вопроса, коряво но работает на 100 процентов

[SolarW]

вы в phphmyadmin "обзор" таблицы смотрели ?

Кстати да, хороший вопрос.
Надо посмотреть содержимое табличек в phpMyAdmin или из консоли (puTTY с кодировкой utf-8) чтобы определить где проблема - в записи данных в базу или при чтении из нее.

[SolarW]

Столкнулся с такой же как и у ТС проблемой.
FreePBX Distro последней версии.
Тоже везде все настроено, кодировки правильные, проверил по всем что нашел руководствам - все равно в базу CDR русские имена пишутся с ошибочной кодировкой.
После пары часов возни обнаружил

Код: Выделить всё

localhost*CLI> module show like cdr
Module                         Description                              Use Count
app_cdr.so                     Tell Asterisk to not maintain a CDR for  0
app_forkcdr.so                 Fork The CDR into 2 separate entities    0
cdr_adaptive_odbc.so           Adaptive ODBC CDR backend                0
cdr_csv.so                     Comma Separated Values CDR Backend       0
cdr_custom.so                  Customizable Comma Separated Values CDR  0
cdr_manager.so                 Asterisk Manager Interface CDR Backend   0
cdr_odbc.so                    ODBC CDR Backend                         0
cdr_syslog.so                  Customizable syslog CDR Backend          0
func_cdr.so                    Call Detail Record (CDR) dialplan functi 0
9 modules loaded

А где собственно cdr_mysql.so в настройках которого писалось charset = utf8 ?
Подтянул его вручную:

Код: Выделить всё

localhost*CLI> module load cdr_mysql.so
Loaded cdr_mysql.so

После этого имена в CDR стали заносится по русски в правильной кодировке.
Задался вопросом - а почему собственно модуль есть а не стартует?
Оказалось вырублен авторами сборки, чтобы не задваивались записи

Код: Выделить всё

[root@localhost ~]# cat /etc/asterisk/modules.conf|grep cdr_mysql
noload => cdr_mysql.so

Поискал почему - оказалось авторы FreePBX Distro не применяют cdr_mysql.so
http://community.freepbx.org/t/autoload ... ript/22626
А применяют res_odbc
Которому чтобы он начал писать CDR'ы по русски надо параметр charset=utf8 добавить в файл /etc/odbc.ini
http://forum.asterisk.ru/viewtopic.php? ... 543#p49583
Добавил этот параметр и вуаля, в CDR имена на русском.

[НиколайМ]

Доброго дня всем!

Почитал данную отличную тему про русские буквы в статистике, но увы, в моем случае, это не помогло.

Имеется Asterisk FreePBX 13 на centos7 x64.

Кракозябры выглядят так: http://prntscr.com/fhqq70
По таблице кракозябр я выяснил, что это неправильная конвертация utf8 в cp1252.

Проверил кодировку в mysql:

Код: Выделить всё

MariaDB [(none)]> SHOW CREATE database asterisk
    -> ;
+----------+-------------------------------------------------------------------------------------------+
| Database | Create Database                                                                           |
+----------+-------------------------------------------------------------------------------------------+
| asterisk | CREATE DATABASE `asterisk` /*!40100 DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci */ |
+----------+-------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

MariaDB [(none)]> SHOW CREATE database asteriskcdrdb
    -> ;
+---------------+------------------------------------------------------------------------------------------------+
| Database      | Create Database                                                                                |
+---------------+------------------------------------------------------------------------------------------------+
| asteriskcdrdb | CREATE DATABASE `asteriskcdrdb` /*!40100 DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci */ |
+---------------+------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

Если я перевожу в utf нужные таблицы ( по советам https://voxlink.ru/kb/asterisk-configur ... n-freepbx/ ), то астериск выдает ошибку при применении конфига через веб-интерфейс, ругается на utf8_general_ci в каких-то конфигах и падает с крашем.

Кракозябры наблюдаются и через SELECT * в бд asteriskcdrdb (таблица cdr).

Удалял базу, снова создавал в разных кодировках - проблема остается. Походу, сам астериск в какой-то кодировке пишет в БД.

ODBC.ini:

Код: Выделить всё

[MySQL-asteriskcdrdb]
Description=MySQL connection to 'asteriskcdrdb' database
driver=MySQL
server=127.0.0.1
database=asteriskcdrdb
username=freepbxuser
password=
Port=3306
Socket=/var/lib/mysql/mysql.sock
option=3
Charset = utf8

my.cnf

Код: Выделить всё

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
symbolic-links=0

init_connect='SET collation_connection = utf8_general_ci'
init_connect='SET NAMES utf8'
character-set-server=utf8
collation-server=utf8_general_ci

skip-character-set-client-handshake

[mysqld_safe]
log-error=/var/log/mariadb/mariadb.log
pid-file=/var/run/mariadb/mariadb.pid

[client]
default-character-set=utf8

#
# include all files from the config directory
#
!includedir /etc/my.cnf.d

Прошу помочи, коллеги!

[НиколайМ]

Проблему через ODBC не победил.
Перешел на cdr_mysql.so:

modules.conf

Код: Выделить всё

;--------------------------------------------------------------------------------;
;          Do NOT edit this file as it is auto-generated by FreePBX.             ;
;--------------------------------------------------------------------------------;
; For information on adding additional paramaters to this file, please visit the ;
; FreePBX.org wiki page, or ask on IRC. This file was created by the new FreePBX ;
; BMO - Big Module Object. Any similarity in naming with BMO from Adventure Time ;
; is totally deliberate.                                                         ;
;--------------------------------------------------------------------------------;

[modules]
autoload=yes
preload = pbx_config.so
preload = chan_local.so
preload = func_db.so
[b]noload = res_odbc.so
noload = res_config_odbc.so
noload = cdr_adaptive_odbc.so[/b]
noload = chan_woomera.so
noload = pbx_gtkconsole.so
noload = pbx_kdeconsole.so
noload = app_intercom.so
noload = chan_modem.so
noload = chan_modem_bestdata.so
noload = chan_modem_i4l.so
noload = app_trunkisavail.so
noload = chan_alsa.so
noload = chan_oss.so
noload = app_directory_odbcstorage.so
noload = app_voicemail_odbcstorage.so
noload = chan_modem_aopen.so
noload = cdr_radius.so
noload = cel_radius.so
noload = res_phoneprov.so
noload = res_digium_phone.so
noload = res_config_ldap.so
noload = res_config_sqlite3.so
noload = res_clialiases.so
noload = chan_mgcp.so
noload = cdr_custom.so
noload = app_minivm.so
noload = cel_custom.so
noload = pjsip_wizard.conf
noload = res_parking.conf
load = format_wav.so
load = format_pcm.so
load = format_mp3.so
load = res_musiconhold.so
load = app_confbridge.com
load = cdr_addon_mysql.so
[b]load = cdr_mysql.so[/b]

Затем, в пустом файле /etc/asterisk/cdr_mysql.conf :

Код: Выделить всё

[global]
hostname=localhost
dbname=asteriskcdrdb
password=
user=freepbxuser
port=3306
sock=/var/lib/mysql/mysql.sock
userfield=1
[b]charset = utf8[/b]

Результ: http://prntscr.com/fhssqf

[whoim]

никогда такого не видел, даже на серверах с явно превышающей норму нагрузкой. FreePBX то небось из iso установленный?

[НиколайМ]

Ставил по этому мануалу https://wiki.freepbx.org/display/FOP/In ... n+CentOS+7

Кстати, периодически кодировка опять слетает. Core reload помогает ненадолго

[RDemon]

Доброго дня всем!

Почитал данную отличную тему про русские буквы в статистике, но увы, в моем случае, это не помогло.

Имеется Asterisk FreePBX 13 на centos7 x64.

Кракозябры выглядят так: http://prntscr.com/fhqq70

Прошу помочи, коллеги!

Используй ANSI ODBC драйвер. В Centos 7 из коробки только UNICODE, который, хоть и нелогично, но некорректно работает с UTF8.
Ставится так:
yum remove mysql-connector-odbc
wget https://dev.mysql.com/get/Downloads/Con ... x86_64.rpm
rpm -ivh mysql-connector-odbc-5.3.9-1.el7.x86_64.rpm

Далее, в odbc.ini
[MySQL-asteriskcdrdb]
driver=MySQL ODBC 5.3 ANSI Driver
...
У меня так зароботало корректно, как и cel, так и cdr.

[GuNeR]

Используй ANSI ODBC драйвер. В Centos 7 из коробки только UNICODE, который, хоть и нелогично, но некорректно работает с UTF8.
Ставится так:
yum remove mysql-connector-odbc
wget https://dev.mysql.com/get/Downloads/Con ... x86_64.rpm
rpm -ivh mysql-connector-odbc-5.3.9-1.el7.x86_64.rpm

Далее, в odbc.ini
[MySQL-asteriskcdrdb]
driver=MySQL ODBC 5.3 ANSI Driver
...
У меня так зароботало корректно, как и cel, так и cdr.

Проблема коробочной версии в том, что просто так не трогая зависимости снести коннектор не получится, т.к. yum предлагает грохнуть вместе сним весь астериск.

Как я сделал:
# rpm -qa | grep mysql-connector-odbc - узнал какой именно пакет установлен (у меня mysql-connector-odbc-5.2.5-6.el7.x86_64)
# rpm -e --nodeps "mysql-connector-odbc-5.2.5-6.el7.x86_64" - снёс только его
# wget https://dev.mysql.com/get/Downloads/Con ... x86_64.rpm - скачал свежий пакет
# rpm -ivh mysql-connector-odbc-5.3.9-1.el7.x86_64.rpm - установил его
Далее в /etc/odbc.ini прописал driver=MySQL ODBC 5.3 ANSI Driver
# fwconsole restart - перезагрузил всё

С этого момента записи пошли на русском, но в CLI и логи начали валиться:

Код: Выделить всё

[2017-10-09 01:55:30] WARNING[1102]: cel_odbc.c:789 odbc_log: Insert failed on 'asteriskcdrdb:cel'. CEL failed: INSERT INTO cel (eventtype, eventtime, cid_name, cid_num, cid_ani, cid_rdnis, cid_dnid, exten, context, channame, appname, appdata, amaflags, accountcode, uniqueid, linkedid, peer, userdeftype, extra) VALUES .....
[2017-10-09 01:55:30] WARNING[8910]: cdr_adaptive_odbc.c:766 odbc_log: cdr_adaptive_odbc: Insert failed on 'asteriskcdrdb:cdr'.  CDR failed: INSERT INTO cdr (calldate, clid, src, dst, dcontext, channel, dstchannel, lastapp, lastdata, duration, billsec, disposition, amaflags, uniqueid, cnum, cnam, linkedid, sequence) VALUES ......

Хотя если проверить БД, то записи туда помещаются. Пока не разобрался в чём причина.

[virus_net]

Добудьте в дебаге полный запрос и выполните руками, чтобы понять какая именно там ошибка при вставке в бд.