IssueTracker

From the method's comment, it is only validating against the number length. So what is missing here is to check:

1. If the number is a valid short number - like the equivalent of US 911: 112 or 110 ... in Germany there ist also 115 and 5 digit numbers starting with 118 (118xx) and 6 digit numbers starting with 116 valid short numbers (116xxx)
2. If the used Region is hasNationalPrefix()
3. If the given number has not used a CountryCode nor a TruncCode

Step 2 & 3 can be done with the currently given set of information and methods of the library (I can provide Java example code for a fix). The First step needs more / accurate information (maybe I am just not aware, that it is already present in some files / configuration) - so I made a separate addition in Java for this kind of check, but I just configured the data for Region DE)

Neither my first language is English. :) Sure, we can somehow manage. I understand about the delay in responses. Please ping back at the earliest so the context is not lost. Thanks!

Legal all settings services numbers names opened Legal platforms my

Hi, it was just the first weekend with some free time to care about this issue again. So here are my further findings:

The current discussion was mainly about the first checkpoint - if it is a German short number in the fix line network.

With our explanation I investigated the behavior and checked it with the current configured meta data against the formal definition of the German Number Plan:

I) The 116xxx subpart has been officially defined as xxx = 000 ... 999 - see top of page 2.

While the meta data just configured the currently assigned numbers

So the first question is, should shortNumberInfo.isValidShortNumber only be true for already assigned numbers or any defined number (like other checks do, because beside just so short list it is not really possible).

So as example 116555 is defined as a sort number (isPossibleShortNumber==true) but not assigned (isValidShortNumber==false)

II) The 118(0)xx subpart is not supported by the MetaData yet!

Here the list of already assigned numbers is much longer and in contrast to the 116 which needs to be aligned on EU level the 118 needs just to regulated in DE, so there might be more "movement" in this assignment.

Here the meta data leads to isPossibleShortNumber==false which is wrong!

Now that I think I know how to configure this, should I make an independent Merge Request out of it?

The second and third point of my initial list can be combined and can be explained best by the requested example:

I extract the call history of German fixline routers, so those entries included strings of phone numbers how they have been used. In German fix line you can call a phone number in the same area just by the number or (like a number of any other area) with the trunc - code + area code + number; or even bei + country code (no trunc code) + area code + number.

To find those numbers in a contact list of a smart phone, I try to normalize those numbers. Sometimes I also have the area code, where the device is operating, so I could generate the full version.

I suppose the main problem is a misunderstanding. When I read in a previous response „So when it comes to 556677, 55X are valid area codes followed by 3 digit subscriber numbers. This is the reason why 556677 is considered as IS_POSSIBLE than IS_POSSIBLE_LOCAL_ONLY. 556677 is a potential full length number - i.e with area ccde.“ This ambiguity seems to be only true for the data model of the library. In the telephone network, it is unambiguously 556677 is a phone 6 digit number without an area code while 0556677 is a phone number with an invalid area code (only 05565 exists … but lets assume 55 would be an area code ;-) ) - but back from this bad area code example, the leading 0 is the trunc code. The problem is, that the library does not make it easy to handle this.

First of all both numbers have the same National Format representation (0556677) 556677 and 0556677

To make my calculation valid for any kind of number plan with a trunc code, I do not calculate with a static 0, but get the trunc code from the MetaData region. This is not directly supported, because the necessary method is not pubic, so I created a pull request - since I have been ask to try it differently. This is why I came across the method in this issue.

Another approach would be to have a method on the phone number like isTruncCodeUsed to get the information if a trunc code and therefore also an area code is used at the beginning of the number. In correlation to this isCountryExitCodeUsed would make sense (similar to country_code_source == FROM_NUMBER_WITH_IDD or FROM_NUMBER_WITH_PLUS_SIGN or FROM_NUMBER_WITHOUT_PLUS_SIGN), because an exit code would imply a country code plus area code (but not necessary a trunc code - like it is in Germany).

For my use case without access to the trunc code meta data a setAreaCode would be necessary, wich sets a trunc code + that area code infront of a number, or replacing an existing area code within a number.

That are my ideas to solve the need, without changing the issued method. What would be the best approach to proceed?

Thanks.

Just did the MRs as proposed in the previous comment:

• 116xxx -> (rejected to Issue)
• 118xx and 1180xx -> (rejected to Issue)

And in addition I found some mistakes at the German geocoding table for DE area codes, which I also corrected -> (rejected to Issue).

Hi,

As mentioned in our contribution policy, we are not accepting PRs for metadata updates. Thanks much for the changes, and helping us to improve the metadata. We will make the respective changes in upcoming releases.

1. We will be not able to support all the 116 XXX numbers as valid short codes as we add support to specific ones, unlike phone number ranges. As you mentioned if 116555 is valid one, we can add support to only that one.
2. Thanks for geocoding updates. One thing: "/" is our usual syntax for "or" / "alternatives" / "at". As these geocoding details are from official plan, we will investigate changes individually and do the needful.

Thanks again for all the improvements suggested. :)

Hi,

I am sorry that I missed the contribution policy part to Meta Data, I just have been in the flow to give back things I improved locally. So here are some notes to your last comment:

• 116xxx it is absolutely reasonable to stick to the (very) short list of assigned numbers. Since those numbers need to be aligned through the whole EU, Germany can't assign new numbers on their own and that makes it unlikely, that the list will grow much. Therefore please do not add 116555, which is not an assigned number. I will make a cross check about 116xxx configuration for all other EU countries so, that the Meta Data would be consistent.
• 118xx / 1180xx it would really be great if you could add this missing part to the short number configuration (I could remove a lot of custom code then ;-) )
• Geocoding, as I explained in my comment of the other issue, some cities names are detailed by further geo information like near by river. So this "/" is not a logical or but just a seperator as example Stolpe is the city name, while Oder is a nearby river. So "Stolpe/Oder" would be in a human sentence "Stolpe an der Oder". For some Cities this river extension is even part of the official like the Frankfurt am Main while on the counter part Frankfurt an der Oder it is just an informal extension.

If I can help you with your investigation, please let me know (sine I already did this for my own list ;-) )

As promised, I made a cross check of the meta Data of the EU countries with the configuration of 116xxx (EU harmonized social hotlines) ... it was a little bit surprising how many configurations I found. Obviously not all Hotlines are operating in every country, but on the other side the style of coding is quite different. And that valid check is mostly stricter than toll free check, where the other way round only once was made (which is more logical: valid is the definition, so it does need to be strict to the assigned, while toll free should be strict to the real tool free. So if there is a new number, it would rather be good to explicitly configure it to toll free, than to valid. Right now it would not be valid but toll free !!!).

x0 (valid check):

116 - 000..999

x1 (assigned check):

116 - 000
116 - 1 - 06|11|23 

x2 (assigned check):

116 - 00 - 0|6
116 - 1 - 17|23

x3 (assigned check):

116 - 000
116 - 117

x4 (assigned check):

116 - 000|111

x5 (assigned check):

116 - 00 - 0|6
116 - 1 - 11|23

x6 (assigned check):

116 - 00 - 0|6
116 - 11 - 1|6|7
116 - 123

x7 (assigned check):

116 - 00 - 0|6
116 - 111

x8 (assigned check):

11611 - 1|7

x9 (assigned check):

116 - 000
116 - 11 - 1|7
116 - 123

x10 (valid check):

116- 0|1 - 00..99

x11 (assigned check):

116 - 00 - 0|6
116 - 11 - 1|7
116 - 123

x12 (assigned check):

116 - 000
116 - 1 - 11|23

x13 (valid check):

116 - 0 - 00..99
116 - 111
116 - 12 - 0..9

And they are used for SN(short number) / TF (toll free) in those countries (country code in breakers it's a EU candidate others are already members). A letter in brackets mean, that the result of the check is the same as x? check but has a different design / coding:

• (AL) = x1; TF=x10
• AT: SN=x2; TF=x0
• BE: SN=x3; TF=x0 (a)
• BG: SN=x4; TF=x0
• CY: SN=x4; TF=x0
• CZ: SN=x0 (a); TF=x5
• DE: SN=x6 ; TF=x0
• DK: SN=x7; TF=x0
• EE: SN=x4; TF=x0
• ES: SN=x4; TF=x0 (a)
• FI: SN=x8; TF=x0
• FR: SN=x4; TF=x0 (b)
• GR: SN=x9; TF=x0
• HR: SN=x11; TF=x0 (b)
• HU: SN=x12; TF=x0
• IE: SN=x11; TF=x0
• IT: SN=x4; TF=x0
• LT: SN=x9; TF=x13
• LU: SN=x4; TF=x0
• LV: SN=x4; TF=x0
• (ME): SN=x0 (c); TF=NONE_116
• (MK): SN=x0; TF=x0
• MT: SN=x12; TF=x0
• NL: SN=x5; TF=x0
• PL: SN=x12 (a); TF=x0
• PT: SN= x7 (a); TF=x0 (a)
• RO: SN=x12; TF=x0
• (RS): SN=x0 (d); TF=NONE_116
• SE: SN=x11; TF=x0 (a)
• SI: SN=x12; TF=x0 (a)
• SK: SN=x4; TF=x0
• (TR): SN=NONE_116; TF=NONE_116

It's not easy to evaluate the correctnes, because the status might be none, reserved (designed) or in operation (assigned).

At least I found out so far that x8 is excluding 116000 as a short number, and Finland, which is using this check is indeed supporting this number: https://www.suomi.fi/services/phoneservice/116000-european-missing-children-hotline-number-emergency-response-centre-agency-finland/f42acfab-5167-464d-89c2-874ae8d81133 (own issue)

Should this become an own issue? And what about further 116xxx findings?