Summary:ASTERISK-17696: international characters in CALLERID(name) should not be escape encoded (for legacy hardware)
Reporter:test011 (test011)Labels:
Date Opened:2011-04-14 21:00:30Date Closed:2011-08-29 21:25:38
Versions:Frequency of
Description:8bit characters in CALLERID(name) should not be escape encoded. (cf. %38%EA)

This is closely tied with client hardware devices' capability. You cannot just have it another way without any legacy support.

I am not even sure there is any client hardware that supports this kind of encoding/decoding. (No, actually I am very sure that there is none in the market can decodes escaped international characters in CallerID display)

Majority of devices support displaying non-encoded characters but can't decode escaped characters, they are doomed as for now. Please put a legacy support (CALLERID pre-1.8 behavior concerning charset encoding which is 'no encoding')

I know there are some devices that do not ring if international characters are present in CALLERID(name) Since they usually don't support UTF-8 or escaped decoding either, new feature in CALLERID is still useless and there are legacy ways to deal with such devices.


Supporting charset and UTF-8 in CALLERID is a noble idea, but it's not being done right.

I am in the region where a local charset is widely used. For a decade, every single SIP hardware in the market is tuned to pre-1.8, and none supports escaped charset decoding in the callerID display. Well, for that matter none supports UTF-8 either. In reality it will take another decade or so.

OK. If you want to encode it for some fancy reasons, fine, however for the hardware compatibility's sake, put an option for a legacy support (I mean non-encoded CALLERID(name) as in all Asterisks before 1.8)

I understand Asterisk in being developed in ISO-8859-1 world and other charsets are, in practicality, very alien, as far as charsets go, UTF-7 and UTF-8 looks very tempting and easy way out, but there are not yet that universal. Please never, ever leave out a legacy support.
Comments:By: Richard Mudgett (rmudgett) 2011-08-29 17:57:27.645-0500

This is chan_sip doing this not the CALLERID function.

I think this is really a duplicate of ASTERISK-16949 which is now in newer versions of v1.8.

By: Richard Mudgett (rmudgett) 2011-08-29 19:02:59.684-0500

Is this still an issue?

By: test011 (test011) 2011-08-29 21:23:09.124-0500

I've just confirmed that with "pedantic=no" fixed the problem. Thank you for the comment.

By: test011 (test011) 2011-08-29 21:25:38.193-0500

in 1.8 with "pedantic=no" fixes the problem. (default is pedantic=yes in 1.8, pedantic=no in 1.6)

By: David Woolley (davidw) 2011-08-30 05:27:40.890-0500

This is actually "not a bug", rather than "fixed"!

As I understand it there was a change from assuming phones are broken by default to assuming that they are standards conforming, but the old behaviour is still available.

By: test011 (test011) 2011-08-30 09:33:44.530-0500

You are quite right. :)