Bug #349
Trunk provided CNAM dropped with CID greater than 10 digits
| Status: | Closed | Start: | 09/01/2010 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | 09/28/2010 | |
| Assigned to: | tshif | % Done: | 100% |
|
| Category: | - | |||
| Target version: | Caller ID Superfecta v 2.2.4 Maintenance Release |
Description
Most of my calls come in over Zap trunks. Incoming CID can be either 7 digits (NXXXXXX) or 11 digits (1NXXNXXXXXX). I prefer to keep the trunk provided CID names when possible so my first Superfecta Scheme has "Trunk Provided" as the only lookup source. Superfecta is not keeping the Trunk Provided CNAM when the incoming CID is 11 digits. It is working OK for the 7 digit CID.
Solved:
Problem is on line 42 of /bin/source-Trunk_Provided.php
existing line:
if($thenumber == substr($this_chan_array[7],-10))
replace with:
if($thenumber == substr($this_chan_array[7],-11))
I have made this change on my system, and solves the issue for me. I include the fix here for comments from others particularly the original author before it gets committed to the repository.
Lorne
History
Updated by lgaetz over 1 year ago
I have pondered this for a few days and am begining to think that line 42 should be changed to this:
if($thenumber == $this_chan_array[7])
I think you should always want to match the strings exactly. Can anyone explain why it was written to only match the final 10 digits?
Updated by lgaetz over 1 year ago
I just found another issue: [[http://projects.colsolgrp.net/issues/227]] discussing the rationale behind matching the final digits on a phone number, which I think is probably applicable to this issue. If the original intent was only to match the final 10 digits of the CID strings then line 42 should have read:
if(substr($thenumber,-10) == substr($this_chan_array[7],-10))
I have not tested this yet, I'm in the middle of a holiday weekend. It occurs that it might be better for others outside of North America to have control over the number of matching digits in case 10 is not appropriate, but that is way beyond my coding skills.
Updated by lgaetz over 1 year ago
- Status changed from New to Resolved
Found someone with the same problem and the solution above corrected it. See http://pbxinaflash.com/forum/showthread.php?t=8104 on PIAF forums. Code change committed to repository
Updated by tshif over 1 year ago
- Status changed from Resolved to QA Testing
- Assigned to set to tshif
- % Done changed from 0 to 10
Updated by tshif over 1 year ago
- Target version set to Caller ID Superfecta v 2.2.4 Maintenance Release
Updated by tshif over 1 year ago
- Due date set to 09/28/2010
- Status changed from QA Testing to Closed
- % Done changed from 10 to 100
This patch fixes the problem identified without causes other detectable issues. Accepted for build 2.2.4.
Thanks lgaetz! Way to go!