[SOLVED] Invalid UTF-8 string

Asterisk Asterisk Support
1

Asterisk crashed and restarted today. I dig through the log for the time when it crashed and it showing up with this:
ERROR[17900][C-000000d4]:json.c:861 ast_json_vpack: Error building JSON from ‘{s: s, s: s}’: Invalid UTF-8 string.

The error seem to have caused by a caller with an invalid character;
“▒15169877970”

In the screenshot, I grep the phone number and see that it was called in normally and then ▒ got added, causing the Json error. Not sure where this came about…

Our system was down momentarily because of this, anything I can do? Please help.

2018-08-27%2014-22-06%20Json%20Error%204
2018-08-27 14-22-06 Json Error 4.png1470×984 33 KB

2

You could try filtering caller ID with the FILTER() function
https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+Function_FILTER

3

What version of Asterisk and libpri are you using? I believe this was fixed quite some time ago.

4

By doing that I’m allow the invalid characters? I’m wondering how it got there though, since I’d rather not alter any filter(s) unless I know for sure it’s something I must do for my environment.

5

Asterisk 13.21.0
libpri version: 1.4.15

6

I’m suggesting you use the FILTER function to filter out undesired characters.

This would set CALLERID(NUM) to only contain valid numerals in it. It’d strip out the + sign so if you need them you’d have to include them in the allowed characters filed.
Set(CALLERID(NUM)=${FILTER(0-9,${CALLERID(NUM)})})

8

Right right. Do you have any idea why it would include the block element (U+2592 ▒ Medium shade)? bug?

9

You need to upgrade libpri to 1.6.0. There was a fix made to accommodate some Lucent switches sending an incorrectly encoded ie for the connected line number which resulted in a garbage character at the beginning of the CALLERID(num) value.

1 Like
10

Hi there. I am fairly new to Asterisk and installed this on a Distro. Do you know if I need to upgrade anything else if I upgrade libpri to the latest?

What is the best way to upgrade libpri? This will probably take down the PRIs so I will test and upgrade after hours.

11

Probably the best way to upgrade libpri is to build from source. libpri has no dependencies except for DAHDI which is needed to build the extra utility programs with libpri.

12

Hi John,

Would you be able to elaborate on where I can set this filter? ASterisk crashed again today because of the same exact issues - ▒ got included in a phone number somehow.

I was told to resolve this is to update libpri, and I don’t know if I have enough knowledge to do something like that, when Sangoma support still haven’t got back to me for assistance.

Thanks so much for your time.

13

Insert the filter statement in your dialplan where ever your incoming calls come in.

14

I’m not sure where to insert this function so it will not get overwritten by Freepbx. Can I put this in extensions_custom.conf?

Thank you for your patience.

Best,
Thank you,

15

I can’t offer any advise for FreePBX, I don’t use that product.

If you had said you were using their product sooner I would have directed you to their support forum at https://community.freepbx.org

16

Relevant FreePBX Ticket - https://issues.freepbx.org/browse/FREEPBX-18082 - and libpri 1.6.0 is in testing now.

1 Like
17

I have run into the same issue before.
Asterisk crashing on a call coming in with invalid UTF-8 string “▒” in front of the Caller ID. I had opened a bug report at the time but it was too late to provide a backtrace.

I had this happen on calls coming from a Digium PRI gateway and I was able to prevent the invalid UTF-8 string “▒” by setting Facility-based ISDN Supplementary Services to Yes on the PRI gateway.
It still remains a bug that Asterisk would be crashing on this, but whatever DAHDI hardware you are using, if you find an equivalent setting, it will prevent the issue from happening.

1 Like