Use libphonenumber to properly format phone numbers

[hanzi]

This replaces the phone number formatting method using strtr() with one that utilises the libphonenumber library (which is PHP port of the Google library with the same name.)

That allows a user to just define the country code where the FRITZ!Box will be used and libphonenumber will handle the rest.

It will automatically apply appropriate formatting for phone numbers and detect whether it's a national or international phone number. See the docblock for the method used:
https://github.com/giggsey/libphonenumber-for-php/blob/master/src/PhoneNumberUtil.php#L2643

Fixes #193

[andig]

/cc @blacksenator

[andig]

LGTM on quick glance. Would appreciate confirmation by @blacksenator

[blacksenator]

I'll do this the next couple of days

[blacksenator]

$countryCode = $this->config['country'] ?? 'DE';

[blacksenator]

analog config.example.php: 'country' => 'DE',

[blacksenator]

'country' => 'DE'

[blacksenator]

@hanzi
Just to be sure:
The conversion may be in accordance with the ITU specifications - but can we also be sure that the FRITZ devices will process defined separators in foreign numbers?
This may not even happen for the vast majority of users - but using the library there is no longer any possibility for individual fine-tuning...
Listen to the FRITZ!Box Callmonitor only digits (apart from SIP) without any separators are displayed. Beside of this: unfortunately there is no AVM documentation which separators can be processed.

Have you tested with AVM devices whether the converted foreign numbers are initiating a dial out? For instance: test calls from the telephone book of a FRITZ!Fon or with a 'Wählhilfe' from the FRITZ!Box GUI?
Conversely, the central convenience function of identifying the caller using a stored telephone book in the FRITZ!Fon should not be lost when a (foreign) call is received.

As I said - possibly a marginal problem - but you never know ...

[blacksenator]

Contributer never updated reviewed topics. Beside of this: Apart from that, the implementation of the extensive library does not bring any real improvement over the manual solution in the config. I suggest to close this topic.

[hanzi]

Apologies, I must have missed the notification for the review in August.

I've renamed the option from defaultCountry to country as requested.

The conversion may be in accordance with the ITU specifications - but can we also be sure that the FRITZ devices will process defined separators in foreign numbers?

I've been using this fork for half a year now, with various international numbers in my address book (from several European countries, India, Taiwan, USA, Vietnam) and never ran into any issues.

Caller ID also works without issues, regardless of formatting in the address book.

As far as I can tell, the Fritzbox happily ignores any whitespace/separators. But as you said, there doesn't seem to be any documentation for that.

Apart from that, the implementation of the extensive library does not bring any real improvement over the manual solution in the config.

I understand the hesitation for including another dependency. That's of course your decision. For me it works quite well and I've also been using it in some customer projects without any issues.

My personal benefits with this solution:

1. It gives me nicely formatted phone numbers that honour the formatting of each country, separate area codes for easier readability etc.
2. It worked better with my existing address book which often prefixes international numbers with 0046 instead of +46. I know that the latter would be more correct anyway, but that's what I've got.
3. There were some other issues with the strtr solution and my address book, but I can't remember them exactly.
4. Configuration feels a bit more straight forward to me (setting a country code instead of having to think about the more technical replacement tables) but that's of course highly subjective.

[blacksenator]

@andig if @hanzi says that it doesn't cause any problems in the interaction of the devices, then I don't see any reasons why it shouldn't be part of the solution.