Bug #219
Choose the CLID charset
| Status: | Rejected | Start: | 10/26/2009 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assigned to: | - | % Done: | 0% |
|
| Category: | - | |||
| Target version: | - |
Description
ISDN caller ID charset are restricted to IA5.
Some SIP phones will accept extended ASCII charset (my Cisco don't and will write a blank line instead of the CLID if it does contain extended chars).
I would suggest that by default we restrict the charset to IA5 and give an option to the user to extend to ASCII if he know that his phone can support it.
I have uploaded in SVN rev 202 a new callerid.php that uses a variable called $charsetIA5 that is coded as true by default in the code.
We just need to add in the superfecta page a checkbox for to toggle this option and update the database accordingly for this new value.
Related issues
| related to Caller ID Superfecta - Bug #215: Choose the CLID charset | Closed | 10/26/2009 | 10/26/2009 |
History
Updated by tshif over 2 years ago
- Due date deleted (
10/26/2009) - Assigned to changed from tshif to jacobsj
- Priority changed from High to Normal
- % Done changed from 100 to 0
- Estimated time deleted (
2.00)
Updated by patrick_elx over 2 years ago
copy of the work pending in feature #215
we will have to redo a full source test when IA5 is disabled to make sure that everything is still working properly. My preliminary tests were ok but I haven't done the same extensive debug session than when IA5 was enabled.
Also, right now it's not a fully IA5 compliant filter I've coded, but just a basic accent removal. There are two or three minor differences between ASCII and IA5 and I should implement these changes later on. But I'm not even sure that our phones will see the difference.
Updated by tshif over 2 years ago
Copy of previous ticket data:
pdated by jacobsj
Couple of thoughts, currently are no completely global variable, the closest they come is variables for an entire scheme. I could added a global variable for this option, but we may want it in individual schemes and here is why:
Admittedly this is a weak argument, but I thought I'd bring it up. Someone could have a set of phones enabled with extended characters sets that are used as part of a call group for international calls, and phones that were meant for US calls. They could have inbound routes and CID schemes set up for those inbound international calls that route to the phones with extended character sets, and use a second CID scheme for inbound calls that go do the IA5 display phones.
Updated by patrick_elx
It's not a big issue to have it by scheme as long as the value is present with the default setting, it just fill the database.
Also we will have to redo a full source test when IA5 is disabled to make sure that everything is still working properly. My preliminary tests were ok but I haven't done the same extensive debug session than when IA5 was enabled.
Also, right now it's not a fully IA5 compliant filter I've coded, but just a basic accent removal. There are two or three minor differences between ASCII and IA5 and I should implement these changes later on. But I'm not even sure that our phones will see the difference.
By looking at the database and the install/upgrade script, I'm not sure that there's a full cleanup of all the pre-scheme era database info. There may be some unused values that are filled by the script. Maybe need to open a new ticket for that.
Updated by bsau about 2 years ago
- Status changed from New to Feedback
This has not been a problem for anyone that I know of at this time. Since the release of 2.2.3, we have not seen any issues here.
Should this ticket be closed?
Updated by tshif over 1 year ago
- Status changed from Feedback to Rejected
Updated by tshif over 1 year ago
- Assigned to deleted (
jacobsj) - Target version deleted (
Caller ID Superfecta - Future Versions)