Closed ameenross closed 7 years ago
Albeit I am a Dutch citizen, I have never heard of this before. Could you link us to some article? Could help implementation by possibly knowing some more details (is 097 only Dutch, for example). Does it start with +31 as other Dutch numbers, and is the only issue that the number is too long?
I would expect it to be common knowledge by now, but here you go, some results of a simple Google query
http://nl.m.wikipedia.org/wiki/Lijst_van_Nederlandse_netnummers
https://www.t-mobile.nl/klantenservice/toestel-en-sim/simkaart/097-nummers
https://forum.t-mobile.nl/overige-abonnementen-351/nieuwe-sim-kaart-12-cijferig-telefoonnr-221546/
@ameenross I guess you've already tried with Kontalk. Kontalk uses libphonenumber both on client and server to verify the format of phone numbers. I'll check if it is supported there.
@ameenross I've been trying inputting a test number in the app, but it fails for everything. Just to be sure I can open a bug to libphonenumber, can you give me an example of such a number? 12-digits including the country code? I guess the initial 0 is the trunk prefix.
The 0 is the Dutch trunk prefix indeed. The 12 digits is including trunk prefix and excluding country code, so like this:
097012345678
International variant would be:
+3197012345678
Looks like an issue has already been filed: https://github.com/googlei18n/libphonenumber/issues/332
I left a note in that issue too. Let's see what they can do :-)
Not sure if it caught your attention, but I filed this: https://github.com/googlei18n/libphonenumber/issues/680
The maintainers don't seem to want to support M2M numbers :-1:
Perhaps we can create a new number database in JSON format or something, using data from libphonenumber. The problem with libphonenumber is that it's both a database and a library to query that database. IMO a database with a clear specification will allow anyone to write some simple library to query it.
I saw that, yes, and that's sad. I'll have to make a fork of the library... I don't know, I don't really have much time to put efforts into this right now... I'm currently doing in parallel 3.0.2 bugfixes, material design and group chat :-) sorry...
I know. I don't think forking is a good idea either. Libphonenumber's internals are aging and I feel there should be a separation between the raw data (which is a project of itself) and a library to query it.
Anyway, the quickest thing to do would be to add some kind of "whitelist" feature that accepts a number even if libphonenumber rejects it. Sounds a bit silly and unnecessary, but the alternative requires a larger time investment.
@ameenross remember that the server does phone number checks too, so this would need a double implementation - that's why I was thinking of forking. Anyway what you are describing is even more challenging than a fork :-)
Anyway, the quickest thing to do would be to add some kind of "whitelist" feature that accepts a number even if libphonenumber rejects it. Sounds a bit silly and unnecessary, but the alternative requires a larger time investment.
Eerrr I wouldn't like that...
Seems like libphonenumber isn't caring much about this... I'm delaying this to 3.2 :-(
https://github.com/googlei18n/libphonenumber/issues/680#issuecomment-218395849 I guess this will require either a fork or a custom implementation in Kontalk...
Unfortunately yes.
Any relevant news on this matter? If Google is not willing to pursue this I think I'm going to make a custom implementation inside Kontalk, though I still have to decide if I'd better fork libphonenumber anyway.
@ameenross any relevant info for me about this format? How should I parse it? Are there specific rules beyond 12 digits and the 097 prefix?
The only extra rule is that 0979xxxxxxxx is a network reserved range. Only 0970 is in use now, but the ranges 0971-0978 will be activated once 0970 is close to being depleted.
I don't ave any news beyond what's posted over at the well-known Github issue. And that's currently radio silence (again).
@ameenross ok thank you. Next step is checking for SMS provider suppprt. I'll need a real phone number to do some tests (mainly send a few SMS to it). Do you or anyone else have it? Please send me an email.
My wife has one. Where do I email to?
devteam (at) kontalk.org. Thanks!
I just discovered that Nexmo and Checkmobi (our number verification providers) are both rejecting the number. That's going to be a problem. I'll contact them and keep you posted.
Quick update: I've contacted Nexmo and they seem to be working on it. It's taking some time for them, but the necessary code changes for Kontalk are here and it works, now it's up to them. I'll keep this open at least until 4.0.0 release.
Great!
It's quite frustrating that Google isn't moving though.
Here I am again with news from Nexmo. Unfortunately they refused to support the M2M numbering in Netherlands because the "verify API should be used to verify people only". Since they can't be sure of that when talking about M2M numbers, they decided not to support this. This leaves me with a few (costly) choices:
Both of them requires some effort that I can't predict how I could allocate at the moment. I've opened a server-side ticket and I'll be closing this one since, on the Android side, everything is implemented.
does your tablet have telephony capability by the way?
I don't have a tablet. I put the SIM card in my wife's phone. She's also using it for VOIP (SIP).
I don't have a tablet. I put the SIM card in my wife's phone. She's also using it for VOIP (SIP).
@ameenross ok, but not for plain GSM telephony right?
No. She has had an incoming call on a number of occasions, so it did work. Outgoing calls are not available though
Ok thanks @ameenross.
Since recently there's a new number range in the Netherlands for use with tablets. These are 12 digits long and start with 097. They are not supported in whatsapp, despite the fact that SMS can be received (in my experience also sent) on these numbers. It would be a boon if Kontalk could support these numbers before whatsapp.
Is there some kind of library that validates the entered number in the app? Are there other things to consider, maybe server side or the service that is used to send SMS?
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.