IssueTracker

NL 0970 https://www.government.nl/documents/annual-reports/2016/02/16/decree-change-of-telephone-and-isdn-services-numbering-plan-for-m2m-applications Definition: "‘electronic communications service for an automated application" Generally not SMS-enabled, but some are (when used in tablets). Same applies to voice calls.

0970 Is not a M2M number. It is a normal number, that can be used to send and receive SMS and voice calls. If this is disabled by the provider than the provider should take care of this problem. So please exclude 0970 numbers from this blacklist.

It is very common that 0970 numbers are given to tablets to use as an internet-only device. But in all cases these can receive SMS messages and therefor should be able to be verified by Signal with the 'libphonenumber'. This is a bug that has been around pretty long now (more than a year and no change).

https://github.com/google/libphonenumber/pull/2499

https://github.com/signalapp/Signal-iOS/issues/4442

https://github.com/signalapp/Signal-Android/issues/9005

https://issuetracker.google.com/issues/140508060

https://issuetracker.google.com/132751288 Validation issue with +47587465985576 Planning to fix this in 2019-Q3

https://issuetracker.google.com/140126539 Netherlands Twilio SMS Number Invalid Planning to fix this in 2020-Q1

Both say this is M2M that needs to be fixed. But it isn't M2M. One of the purposes could be M2M. +316 was also used for M2M. And +3197 replaces the use of +316 for M2M. But this doesn't mean that it is restricted to M2M.

Let's fix this bug because all my Contacts are moving away from Whatsapp before 8-februari-2020. 2021-Q1 would be just one year over the deadline you gave yourself 2 years ago.

I don't understand why the current solution is accepted. Apparently there is functionality that is not working, and frustrating. There are a few people that know this is caused by the LIB this bugtracker is for, but most just don't understand why it is not working.

And you tell me that supporting numbers starting with 097X and having 12 digits are an issue? Because usual mobile length is 9? But there are lot's of countries that have more than 9 digit length numbers. So it can't be an issue.

You have a API that validates numbers... because the isPossible test... but it does not validate valid numbers... and you say it gives false positives... but every 097X number can be a valid number. Just like every 06 number can be a valid number, but does not have to be a valid number. So right now it solves nothing. It gives false positives and false negatives.

Hi, Sorry, the library cannot do anything best here (for now) because of aforementioned reasons. We recommend products to whitelist the 097X NL ranges/any M2M ranges on their own, until we add a separate util. We will post here as soon as we have an update. We appreciate your patience. Thanks!

Hoi, for the non-technical people, here is a summary of the situation AIUI.

libphonenumber has two methods, isValidNumber() and isPossibleNumber(). The first one uses the full validation on canonical phone numbers and as such would correctly work with the change to add the 12 digit numbers with 097 prefix in NL. The second one is a "quick check" that only checks length, but can also work with local numbers without area code prefix. So if the 097 range was added as a mobile number then isPossibleNumber() would start accepting 12-digit NL numbers beginning with 06, which is considered undesirable.

The core of the issue is that the library wants to not only validate the numbers but provide information about how it can be used. But even this is fuzzy, after all, you can send an SMS to a landline here and it will get read out to you. The network (here) doesn't actually distinguish available services based on the number. The new ranges were added because the available mobile ranges were running out due to all the non-mobile devices getting SIMs. The new 0970 range has been made compulsory for all data-only connections for laptops, tablet, PIN terminals, snack machines, lift, etc for services which rarely or never do voice calls. You can make calls to them, but it's not their primary purpose. And I'm pretty sure 112 will work from them as well.

And in particular, if you want WhatsApp on your tablet, you will need to receive an SMS on a 0970 number.

If it were up to me I'd add a new type "dataonly" or something and call it a day, though maybe it's different in other countries. The fact you can call them is kinda beside the point.

Subj: “Rollout of supporting NL M2M numbers as mobile in one of upcoming releases.

Hi,

TL;DR Netherlands 097 "M2M" range will be supported by libphonenumber as category MOBILE.

@Background / Objective:

• We are going to support NL M2M (Machine to Machine) numbers (11 digit 97X numbers) as mobile numbers based on recommendation from Netherland's numbering authority. Evidence: https://www.acm.nl/en/publications/information-about-dutch-097-numbers-non-dutch-providers.
• In NL, these numbers can be SMS provisioned end points with voice capabilities, though M2M numbers are generally for communication between machines.
• M2M is marked as one usage for them, but they are also marked as H2H (human-to-human), and we are receiving a lot of complaints from users because of the fact they are not recognised as valid.

@Impact on API results:

• After the change, PhoneNumberUtil.isPossible() API will consider any 11 digit number as a possible phone number in NL.
• PhoneNumberUtil.isValid() API does more strict validation than the above one. This returns true only when the input 11 digit number has the right prefix, i.e 97.

@Possible breakages if you already have implemented workaround for whitelisting these numbers on your own:

• This feature request has been long pending because of ambiguity around M2M standardisation. In the meantime, we encouraged clients to have their own workarounds to whitelist these numbers.
• If you have done so, we recommend you to watch our release notifications (in email) and release notes on Github. If they include NL M2M range support, please fix your client code against that release version.

@What changed since 2016 and why is this (not) a slippery slope In 2016, there was a lack of official guidelines about these numbers and the majority of what we knew came from user reports. Since then, official authority has explicitly stated that this range “should be made accessible, just like other, regular number series from the Netherlands” and that “you can set up a voice and SMS connection towards prefix +31-97 in the same way as you have done already with the +31-6 series.[...] you should enable your systems for voice telephony for the numbers in the +31-97 series”. This means, however, that there might be cases where the library would categorise a number as a valid mobile number, but in reality, the particular number is used as pure M2M, is not SMS or voice-enabled. There is not much we can do from our side about this, since we always follow official guidelines.

So clients should be aware that there is a possibility of false positives in the NL MOBILE category. The library will continue to not support M2M numbers in general.

Hello,

I have a few questions:

1. Is there any update about this?
2. Could you give us an approximate deadline for when will this numbers' support be operative?
3. Could you provide the link to the GitHub issue/PR we're supposed to watch?
4. What workarounds are currently possible?

Thank you.