Status Update
No update yet.
Comments
kk...@google.com
Thank you for taking the time to improve libphonenumber!
We generally support short codes which are already assigned and not just allocated for future use. This is done to avoid false positives. We add numbers only when they are assigned to a carrier/organisation based on the official evidence or public documents.
Sometimes it so happens that we support few codes as toll-free which in reality resulted in charges, so we would like more due diligence to ensure users do not incur surprise charges. Anyway in this case we are aware that 116xxx numbers are Harmonised European Services of Social Value and are always toll free.
As mentioned by you, we support only few of the numbers in 116xxx as they are the only ones assigned. But we will investigate more on the validity of all 116xxx short codes based on the document you have provided and get back to you ASAP.
em...@anrufliste.com
Hi,
in another issue I commented an
What is interesting is, that CZ is the only country where the meta data do it exactly the other way round (full
Furthermore the coding style is not very harmonized in the meta data, which makes a check very difficult.
Quick finding is, that for Finnland it is
em...@anrufliste.com
Hi,
Maybe the best argument is coming from the project’s own
What does it mean for a phone number to be valid?
Our phone number library can tell that a number range is valid when there is sufficient official documentation, with some latency after this fact is brought to our attention via issue reports or notifications (see below for more information on where our metadata comes from). A valid number range is one from which numbers can be freely assigned by carriers to users.
So it clearly define, that the lib should take the assignable range, not the assigned numbers.
If the statement in
We generally support short codes which are already assigned and not just allocated for future use.
is also true, maybe you should make the exclusion of short numbers from the general approach clear on the FAQ by mentioning it in the cited paragraph.
kk...@google.com
We have received confirmation that 116xyz is assigned in Germany. Thanks for providing all the details we need! We've accepted this issue and will fix this in an upcoming release.
Join our discussion group (
Please note that you have submitted this information with the knowledge that we may use, modify, reproduce, publicly display, and distribute the information in accordance with our open source policies. Please let us know if you did not intend to submit the information for such use.
@Finland - 116000
We have created a separate bug
kk...@google.com
Sorry for accepting the bug earlier. As mentioned in
When we add specific 116xyz as valid short codes, our system automatically adds the complete 116xyz as TOLL FREE. This makes sense because our first priority is the validity of a number. Only if the number is valid the cost of these numbers will be accounted. If it's not valid then it doesn't matter even thought they fall into Toll Free.
Other check we do if its 'possible number' that could be valid in the future, so if you try checking 116213 our demo result shows that isValidShortNumber() - FALSE but isPossibleShortNumber() - TRUE.
Regarding your
About your
Closing this bug as working as intended.
Description
The current Meta Data for German short numbers starting with 116 are not covering any valid number as defined in the official 116xxx ruling (
In addition compare the toll free check, where the whole 116xxx range is already used. Without that change, a number would be marked as not valid but toll free, which would not make sense.
The other way round would be ok and even more future. If a new number is assigned in this range, it would be instantly checked as valid, but only toll free if manually added (if that is really tool free). Right now it is the opposite, so if the new number is not toll free, we directly have to false informations (not valid but toll free).