BUG Callerid Superfecta handling of + in callerid

[Rrrr]

I wonder if this is a bug or if it is by design...it does not work for me...

Within custom from-trunk contexts I unify any local callerid number to +e164. This helps the extensions to see which country the call is from and enables them to call back.
Example:
Calls from 0650xxxxxx were changed into +31650xxxxxx

I used Superfecta 2.2.5beta1 (pbxinaflash 3.6) and lookups of +e164 were successful.

However, when I upgraded to Superfecta 2.11.3 and pbxinaflash 3.11 (Raspberry Pi), I found out that the number passed from Asterisk to Superfecta lacks the + and the second digit.

/var/www/html/admin/modules/superfecta/agi/superfecta.agi: CID Superfecta: The number passed from Asterisk is: 1650xxxxxx

This is only happening when callerid contains a +, because when I unify callerid's to 00e164, then Superfecta correctly gets the number passed from Asterisk.

I would like to continue to work with +e164 format within my environment...

Incredible PBX 3.11.7 for Raspberry Pi
Ast 11.3.0-rc1
Freepbx 2.11.0.1

 

[tm1000]

It usually strips the + symbol because that symbol is in none of the online lookup sources so you'd get no results.

 

[Rrrr]

Yes, but ...

1) This worked in the past. In the new version, the + appears to being dealt with differently.
2) Why also strip the 2nd digit?

The below solves the issue in my opinion: I edited superfecta.agi as follows:

//Remove leading +1-9 on numbers.
//$agi->request['agi_callerid'] = trim(preg_replace('/^\+[1-9]/', '', $agi->request['agi_callerid']));
//$agi->request['agi_calleridname'] = trim(preg_replace('/^\+[1-9]/', '', $agi->request['agi_calleridname']));
//Rrrr change:
$agi->request['agi_callerid'] = trim(preg_replace('/^\+/', '', $agi->request['agi_callerid']));
$agi->request['agi_calleridname'] = trim(preg_replace('/^\+/', '', $agi->request['agi_calleridname']));

I understand online sources work without + but can they deal with 00 as prefix?
In case of 00 in the callerid, the script does not care to remove the 00, although I am not sure it works for online lookups.

Asterisk phone book as Superfecta lookup source
I was thinking also about compatibility with Asterisk phone book: here you would probably want some entries to have the full international prefix (00 or 011) for foreign numbers in case you dial out from the phone book?

In that case, it would be better if Superfecta would change every + into 00 or 011 (assuming online sources can deal with this)

//Rrrr change:
$agi->request['agi_callerid'] = trim(preg_replace('/^\+/', '00', $agi->request['agi_callerid']));
$agi->request['agi_calleridname'] = trim(preg_replace('/^\+/', '00', $agi->request['agi_calleridname']));

 

[Rrrr]

On another thought : replacing + by 00 or 011 as proposed by myself is ugly and nonstandard.

I still believe Superfecta should be able to deal with + as it did in the past as some would use Superfecta to check a number in an own database with + as international format.
Then dialing out that number would enable any system to replace the + by 00 or 011 whereever the system is based.

To get a match in online sources, the user should be careful to add +|X. in the CID rules of Callerid Superfecta.

With the + not being removed, one (I am not skilled enough to do that) should probably modify superfecta.agi further to ensure + does not cause this:

Not a valid number

 

[tm1000]

I need lgaetz to comment on this before I make a decision. Changing this now could break a lot of people but I understand your concern.

 

[Rrrr]

I see, you are right with your test, but I see Superfecta seemingly(!) stripping + from CID.

It is tricky. This is what I used in the past with superfecta version 2.5.5beta1 in combination with Asteridex and all numbers stored in + format:
Try this +31|0031+ or 00+|31z.
If processed with phone number +31123456789 you will see a Matched CID Rule with 00311234
When searching Asteridex, Superfecta 2.5.5beta1 somehow finds a contact with +31123456789 and comes with a name (matching on the 10 rightmost digits)

(Only superfecta.agi now returns not a valid number)

While Asterisk phonebook does not accept +, note that Asteridex does accept + as may other data sources that users want to search.

Note that it is not common in Europe to store e164 format, numbers usually have leading 00, + or 0.
So assuming this
a. a (European) user could have the following formats in one data source like Asterisk phone book: 00e164 and local format with or without leading 0.
b. a (European) user could have the following formats in one data source like Asteridex: +e164, 00e164 and local format with or without leading 0.

whereas Superfecta worked different in the past and that currently it does not work with + or rightmost matching,

I have developed a proposal as follows and show the logical CID Rules for it:

Proposal (more intuitive):
Allow a user option to either strip the + (and not the second digit!) or replace the + by 00 (or 011 or whatever prefix).
In case the users chooses to replace by 00, these could be the
CID Rules:
- international numbers : 00z.
- local numbers with leading zero: 0+00CC|z. (where CC represents 1-3 country code digits)
- local numbers without leading zero: z.

Alternative (not common for people in Europe):
If you would just strip the + (and not the second digit!) then the CID rules would be different and more confusing.
The users could mistakenly compare international callerid's with local numbers in the data source.
CID Rules:
- international numbers : 00+z. (possible clash with a local CID number being prepended with 00)
- local numbers with leading zero: 0+CC|z. (possible clash with CC eg. 972 (Texas) and 972 (Israel))
- local numbers without leading zero: z. (possible clash with CC eg. 972 (Texas) and 972 (Israel))

I showed the alternative above to demonstrate it could lead to anomalies in matching numbers.
I apologize for the long message, its getting late.

Question: will Superfecta deal properly with online sources if the CID has 00?