This issue was created to address the problem that German fixed-line numbers are always normalized, even if no NAC introduces an NDC. As a result, a newly added CC creates a completely different number. Unfortunately, this issue has not been resolved yet. During the discussion, further examples were raised, which led to the creation of two more issues. However, it’s possible that this has caused confusion about which parts of these issues have been addressed.
2021-03-12 - Validation issue with +4911833
This issue addresses special short codes used for phone number directory assistant services. This issue has been resolved.
This issue pertains to the EU-wide special social number short code definition. Although the regulation clearly defines a range, PhoneLib is not validating against that range, but against a list of currently assigned/operated numbers. At least for the German number space, as mentioned in the initial issue discussion (see first one above), the library is only partly or even completely checking the whole range in other EU number spaces.
On the one hand, the FAQ(https://github.com/google/libphonenumber/blob/master/FAQ.md) states that “valid” does not mean “numbers are currently assigned to a specific user and reachable.” On the other hand, it states that “a valid number range is one from which numbers can be freely assigned by carriers to users,” which is not the case for EU-wide numbers that require special clearance.
While it seems that the last point is the argument for rejecting the issue (which was phrased around TOLL FREE calculation), it is intended, and other EU spaces are stated as needing correction but have not been corrected yet (as of October 2023 - more than two years later).
After a long discussion and closing the issues as stated above, we decided to implement a minimal fix for normalizing German Phonenumbers for our internal use, to support the phoning capability of Deutsche Telekom Smart Speaker. We also set up test cases to verify if PhoneLib behavior changes to correctly normalize the currently failing cases, so that our implementation would become unnecessary.
We also discovered, during its development, that the geolocation method uses BenetzA given labels, which include abbreviations. For a smart speaker, we needed a “speakable” label - so we created the following issue and added our own list to our interim solution.
2022-03-21 - Germany (DE, +49): Update geocode details
We submitted a change request of 34 corrected labels to Google’s libphonenumber library, which was rejected due to the lack of an official reference.
However, we have provided a test case to verify if the labels are corrected in our phonenumber-normalizer repository.
Although the Smart Speaker has been retired, we identified other projects that could benefit from the wrapper and open-sourced it on May 3rd, 2023. While we are currently maintaining the basic implementation, the previous discussion is catching up to question if we should extend the knowledge of the German Number plan to other functions as validating. When we have further insights, we will report them as issues, re-engage with Google, and list the new issues in this file.
BnetzA described special case for NDC 212 and 621 the first one is correctly recognized by geocoder and the two cities are correctly labeled. But the second case is not recognized and only the city Mannheim is used for labeling and not Ludwigshafen.
We have provided Ludwighafen in our labeling data.