Thank you guys but I’m giving up 
Will wait for the official release of FreePBX 13 and look how fresh setup will handle Сyrillic characters.
Andrew, there might be a way to handle this without doing too much of an hack…
If the information that get’s copied into the CDR database if first encoded using base64 then decode for the CDR reports Asterisk would not actually see the UTF-8 characters…
If that actually work then UTF-8 support in FreePBX would be even more complete without even having to change anything on the Asterisk side of things…
I do not know why CID Superfecta does is but there is already CIDSFSCHEME which is encoded in base64…
Sure we can’t store as many characters in the field after that but is the length of those database fields actually important or can we make them larger?
Thank you and have a nice day!
Nick
You seem to be missing the fact that freepbx does not insert into the cdr table. Asterisk does directly. Freepbx can’t do anything here.
But it insert information provided by FreePBX or something like CID Superfecta…
If the fields Asterisk insert in the CDR database (it looks like they are passed to Set’s that assign cdr(cnam) and other similar variables) are encoded using base64 won’t Asterisk blindly use them and insert them in the database?
Could this work?
The CDR report would only need to deencode before producing the report after…
It’s only an idea, maybe I am completely wrong about this…
Thank you and have a nice day!
Nick
No. FreePBX (CID Superfecta) sets the CID(name) variable in Asterisk, Asterisk then writes this to the database. NOT FreePBX.
Sure. That could work. I’m not going to spend the time doing that though. Firstly because it’ll piss off everyone who is using CDR outside of FreePBX, which many do.
Here is a proposed solution: http://issues.freepbx.org/browse/FREEPBX-10392
Let me know if it works for you guys and I will then use it
Лол (Lol)…
I tried
this: http://blog.oneiroi.co.uk/mysql/mysql-forcing-utf-8-compliance-for-all-connections/
and this: http://stackoverflow.com/questions/3513773/change-mysql-default-character-set-to-utf-8-in-my-cnf
and a few others I have lost the links to (one of which was in cdr_adaptive_odbc.conf)
but I did not stumble on that fix…
It works wonderfully for me both with my test entries and another one I did expressly for Andrey (arakhm)
2015-09-29 18:58:28 1443567508.3 "Привет "<200> <5555551212> Dial 7775551212 ANSWERED 00:13
Привет (Privet but pronounced priviett is the casual way to say “hi” in Russian which I am not sure if it’s what Andrey speaks but these are Cyrillic letters so it’s as good a test as any…).
I was going to suggest other things which could be done but as far as I am concerned this it the best fix of them all…
The Asterisk guy I talked to said certain combination of databases in certain conditions could support UTF-8 and with this fix the distro seems to meet these conditions and is a relatively controlled environment so it’s a lot easier to make sure it stays that way…
Tstar did a very nice find… I was searching for something like this yesterday but never found this…
Thank you and have a nice day!
Nick
OK, I spotted one problem but it’s most likely fixable considering the info I believe comes from the CDR table and the CDR reports work wonderfully now…
UCP (which I never used before today) is unable to display properly encoded UTF-8 but is very happy to display double-encoded UTF-8 (what I described above) for the CDR/CEL stuff…
Properly encoded UTF-8 (which is correctly shown in the CDR reports) is replaced by question marks and the double encoded stuff displays correctly…
Whatever recipe was used to make the CDR reports work with UTF-8 (I mean before Tstar 's fix) should most likely be used with UCP…
Thank you and have a nice day!
Nick
What a simple sulution! That short string works perfectly.
Thanks.