Forwarded numbers like "1111&2222"

[aj3423]

Hello~

Came across a new issue with a forwarded call that contains a number formatted like "1111&2222" (two numbers concatenated with an '&').
This & isn't manually added, in CallScreeningService.onScreenCall, the details.handle.schemeSpecificPart already contains this concatenated string.

Reporting it to PhoneBlock works, but regardless of how many times it's reported, when queried later, the result is always A_LEGITIMATE. Looks like this format isn't being handled yet.

How should we handle this format?

[haumacher]

Can you please give more details, what a "forwarded call" is? Under what circumstances occurs such number in the call screening service?

[aj3423]

Wow.. Thanks.

The number looks like:

I can't find any "official" document about this, but from AI and another user, maybe this is a forwarded number.
In the phone app, the & is removed, it's logged as "919896593919371062". But I think the & is quite useful and shouldn't be simply removed.

Full discussion here: This issue: aj3423/SpamBlocker#488

[haumacher]

OK, if those are two independent numbers, shouldn't they be checked independently - check both numbers for SPAM and if one is spam then consider the call to be spam. And when reporting spam - report both as spam?

[aj3423]

You mean, it will be processed on the server side by cutting off the second part? For example, when "111&222" is queried/reported, it gets treated as just "111"?

Looks like a nice workaround. Not sure which part is the origin number and which is the forwarded one, but I think either would be fine.

[haumacher]

I meant this processing should be done by the client of the API. OK could also be done on the server - but yes, what exactly doe these two numbers mean - which one is the origin?

[aj3423]

Ok, I'll truncate the second part and only query/report "111".

which one is the origin?

I don't know, since both of these two numbers involved in this spam call, reporting either one should be fine.

[aj3423]

From this image, the first part can be different, the second part is always the same, so I think the second part is the origin number. I think we better use the second part, query/report "222"?

[aj3423]

Ok solved aj3423/SpamBlocker#488 (comment)

Thanks for the quick reply, and happy new year~