Bug #33: National dial prefix "0" is hardcoded - L2CPBG - Projects @ SHBE.NET

Actions

Copy link

Bug #33

closed

National dial prefix "0" is hardcoded

Added by Jörg Ebeling about 3 years ago. Updated about 3 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Jörg Ebeling

Target version:

0.9.1

Start date:

03/30/2021

Due date:

04/02/2021

% Done:

100%

Estimated time:

Description

At the moment there's a national dial-prefix-number "0" hardcoded within L2CPBG (as well as the international dial prefix is hardcoded as "00").
This is not applicable for all countries and need to become configurable.
I.e.:

[location]
  dialprefixint  = 00
  dialprefixarea = 0

so that countries which do not need to dial an area-prefix (like Poland) get useful responses (by changing/removing this dial prefix).

Files

Download all files

l2cpbg-0.9.1-beta-3_linux-amd64.tgz (9.25 MB) l2cpbg-0.9.1-beta-3_linux-amd64.tgz		Jörg Ebeling, 03/30/2021 11:28 PM
l2cpbg-0.9.1-beta-4_linux-amd64.tgz (9.25 MB) l2cpbg-0.9.1-beta-4_linux-amd64.tgz	No need to drop DB after location changes	Jörg Ebeling, 04/02/2021 01:38 PM
debugpoland-2021-04-02.vcf (658 Bytes) debugpoland-2021-04-02.vcf	Sample addressbook with two Polish contacts	Jörg Ebeling, 04/02/2021 01:38 PM
l2cpbg-0.9.1-beta-5_linux-amd64.tgz (9.25 MB) l2cpbg-0.9.1-beta-5_linux-amd64.tgz		Jörg Ebeling, 04/02/2021 05:46 PM

History
Notes
Property changes

Actions

Copy link

Updated by Jörg Ebeling about 3 years ago

File l2cpbg-0.9.1-beta-3_linux-amd64.tgz l2cpbg-0.9.1-beta-3_linux-amd64.tgz added

Implemented

[location]
  intprefix  = "00"
  areaprefix = "0"

Actions

Copy link

Updated by Jörg Ebeling about 3 years ago

Status changed from New to Feedback
% Done changed from 0 to 100

Hi Pawel

Please drop your Database before trying the attached beta, by simply deleting the DB directory you've configured within your config.
You also need to apply the following settings:

[location]
  country       = "PL"
  int           = 48   # Your international dial code. 1 = US, 49 = Germany, ...
  area          = 68   # Your local area code (without a leading 0)
  intPrefix     = "00" # Dial prefix for international calls
  areaPrefix    = ""   # Dial prefix for national calls
  maxarealength = 7

Take a special remark to the two *Prefix settings which need to be configured as string values!
Also take attention that your maxarealength is 7! (and not 9 if I understand https://en.wikipedia.org/wiki/Telephone_numbers_in_Poland right).

Please also take into consideration that the insecurecert is not hardcoded anymore in this beta.
You also need to add:

[dav]
# insecurecert controls whether a client verifies the server's certificate
# chain and host name. If insecurecert is true, crypto/tls accepts any
# certificate presented by the server and any host name in that certificate.
# In this mode, TLS is susceptible to machine-in-the-middle attacks unless
# custom verification is used. This should be used only for testing or in
# trusted environments.
insecurecert = true

to your config file.

Looking forward to your response/result ;-)

Actions

Copy link

Updated by Pawel Wasylewicz about 3 years ago

Hi Joerg

In my case, the result is still not correct.

What is important to me is that I give a 9-digit mobile number there.

This number comes from Radicale in CardDAV.
The numbers are correct and I don't want to add anything to them.

I am not able to configure [location] parameters so that nothing sticks to my Radicale numbers.

Even if I set maxarealenght = 9 and send 9 digital numbers, the area is stuck to them. If I give a greater or lesser value of maxarealenght, UCM does not accept the value and does not import data.

Worse still, the value area can't be empty, if it could be empty then I would leave it like that.

In my opinion, you should treat landline numbers (classic phones) differently than mobile numbers. For landline (classic) telephone numbers, the transformations you have designed should follow. However, for cell numbers you either do not make any transformations or define them separately, rather for adding the international prefix (00 or +).

For me, the best (fastest) option would be to turn off transformation on phone numbers.

Probably my combination is that I have to send this mobile number to UCM as the main number because it is an obligatory field and I have mobile numbers everywhere in Radiclae.

Paul

Actions

Copy link

Updated by Jörg Ebeling about 3 years ago

Status changed from Feedback to In Progress
% Done changed from 100 to 80

Hi Pawel,

thanks a lot for your feedback and your patience!

Pawel Wasylewicz wrote in #note-3:

...
In my case, the result is still not correct.

Shame on me.

What is important to me is that I give a 9-digit mobile number there.

This number comes from Radicale in CardDAV.
The numbers are correct and I don't want to add anything to them.

I fully consent!
It's one of my main targets that the user shall not need to adapt their CardDAV numbers in any way.
If expect that your numbers in Radical are simply stored i.e. as "68 xxx xx xx", "65 xxx xx xx" or even "+48 68 xxx xx xx", "0048 68 xxx xx xx" (with or without spaces, doesn't matter)
Also "xxx xx xx" should work, but I already learned by you that you always have to enter the area code in Poland and as such it would be a needless variation.

I am not able to configure [location] parameters so that nothing sticks to my Radicale numbers.

Even if I set maxarealenght = 9 and send 9 digital numbers, the area is stuck to them. If I give a greater or lesser value of maxarealenght, UCM does not accept the value and does not import data.

Your maxarealength should be set to 7 (if I interpret https://en.wikipedia.org/wiki/Telephone_numbers_in_Poland the right way)?!
Your local area code is "68" and whithin that area you've a max of 7 digits!? (two digit local area code + 7 digits within a local area = 9 digits).

Worse still, the value area can't be empty, if it could be empty then I would leave it like that.

Unfortunately not an option (by design). You need to configure your local area code within [location].
You need to set [location] areaPrefix = ""

But I already wrote it and I think you also configured it the right way as well as you dropped your old l2cpbg database.

I expect another failure of mine.

I'll do some more testing to find out whats wrong.

In my opinion, you should treat landline numbers (classic phones) differently than mobile numbers. For landline (classic) telephone numbers, the transformations you have designed should follow. However, for cell numbers you either do not make any transformations or define them separately, rather for adding the international prefix (00 or +).

Regarding https://en.wikipedia.org/wiki/Telephone_numbers_in_Poland Poland has a very easy and simple phone number assignment. And according to that description I don't see a logical difference between a landline or mobile phone number assignments.
What's different between landline and mobile number assignments (I don't see)?

For me, the best (fastest) option would be to turn off transformation on phone numbers.

Let me do some debugging first.

Probably my combination is that I have to send this mobile number to UCM as the main number because it is an obligatory field and I have mobile numbers everywhere in Radiclae.

I'm unfortunately not aware of UCM. Might also be that UCM changes the request in a way I don't handle correctly.

I'll build some test cases and do some sample ldapsearch'es on weekend. We'll get it! ;-)

Actions

Copy link Download all files

Updated by Jörg Ebeling about 3 years ago

File l2cpbg-0.9.1-beta-4_linux-amd64.tgz l2cpbg-0.9.1-beta-4_linux-amd64.tgz added
File debugpoland-2021-04-02.vcf debugpoland-2021-04-02.vcf added

Hi Pawel.

First of, I made a new beta, but it doesn't change anything on the phone number logic. It only skip the need to delete the DB after location changes.

Unfortunately I can't figure out whats wrong.

Here's what I did:

I configured my l2cpg how I think it has to look for a Polish resident like you:

[location]
  int           = 48
  area          = 68
  areaPrefix    = ""
  maxarealength = 7
  country       = "PL"

Then I build a small addressbook with two polish sample contacts (I also attached it to the ticket if you wanna test/check it).
Here's the minimalistic view of the relevant entries:

BEGIN:VCARD
UID:d4feda09-d17e-4c87-ba04-a15e981d4812
FN:Pawel (nicely formatted)
TEL;TYPE="HOME,VOICE":+48 68 123 45 67
TEL;TYPE="WORK,VOICE":68 123 45 67
TEL;TYPE=CELL:451 234 567
END:VCARD

BEGIN:VCARD
UID:1d7afcd0-89dd-4536-8adc-c1c6ee2f4aa7
FN:Person in other Area (ugly entered)
TEL;TYPE="HOME,VOICE":651234567
TEL;TYPE="WORK,VOICE":(65) 76 54   321
TEL;TYPE=CELL:(600) 654 321
END:VCARD

As you can see, I tested with different variants of number formats.

Lastly I fired an ldapsearch:
ldapsearch -L -H ldap://<l2cpbg's IP>:<and port> -b "dc=SHBE, dc=net" -D "cn=<bind dn>" -x -w "<bind password>" -s "sub" "(|(cn=*))" cn telephoneNumber homePhone mobile

and get returned:

# d4feda09-d17e-4c87-ba04-a15e981d4812, SHBE.net
dn: uid=d4feda09-d17e-4c87-ba04-a15e981d4812, dc=SHBE, dc=net
cn: Pawel (nicely formatted)
telephoneNumber: 68 123 45 67
homePhone: 68 123 45 67
mobile: 451 234 567

# 1d7afcd0-89dd-4536-8adc-c1c6ee2f4aa7, SHBE.net
dn: uid=1d7afcd0-89dd-4536-8adc-c1c6ee2f4aa7, dc=SHBE, dc=net
cn: Person in other Area (ugly entered)
telephoneNumber: 65 765 43 21
homePhone: 65 123 45 67
mobile: 600 654 321

For me the result look fully as I expect.

I also tested with a phone and the result look also fully okay (for me).

Actions

Copy link

Updated by Jörg Ebeling about 3 years ago

Status changed from In Progress to Feedback
% Done changed from 80 to 100

Actions

Copy link

Updated by Pawel Wasylewicz about 3 years ago

Jörg Ebeling wrote in #note-4:

Hi Pawel,

thanks a lot for your feedback and your patience!

Pawel Wasylewicz wrote in #note-3:

...
In my case, the result is still not correct.

Shame on me.

What is important to me is that I give a 9-digit mobile number there.

This number comes from Radicale in CardDAV.
The numbers are correct and I don't want to add anything to them.

I fully consent!
It's one of my main targets that the user shall not need to adapt their CardDAV numbers in any way.
If expect that your numbers in Radical are simply stored i.e. as "68 xxx xx xx", "65 xxx xx xx" or even "+48 68 xxx xx xx", "0048 68 xxx xx xx" (with or without spaces, doesn't matter)
Also "xxx xx xx" should work, but I already learned by you that you always have to enter the area code in Poland and as such it would be a needless variation.

Exactly in Poland, it will not work to enter numbers without the zone prefix (68, 22, 60 ..), our landline numbers (cable telephones) must always have 9 digits. In this case, transforming the number with the prefixes does not matter.

I am not able to configure [location] parameters so that nothing sticks to my Radicale numbers.

Even if I set maxarealenght = 9 and send 9 digital numbers, the area is stuck to them. If I give a greater or lesser value of maxarealenght, UCM does not accept the value and does not import data.

Your maxarealength should be set to 7 (if I interpret https://en.wikipedia.org/wiki/Telephone_numbers_in_Poland the right way)?!
Your local area code is "68" and whithin that area you've a max of 7 digits!? (two digit local area code + 7 digits within a local area = 9 digits).
Either I don't understand this mechanism or we have a discrepancy here. Look, I can't have a 7-digit phone number in my Address Book (CardDAV). This number will never work because it is devoid of information about the numbering zone.
Remember one thing in such a construction as in Poland, it may happen that we have duplicates of 7-digit numbers (between zones when the numbering is the same) but by adding 2-digit zone numbering we get rid of duplicates.
For example, 68 453 01 02 and 22 453 01 02.
Therefore, in Poland there are no 7 digit numbers. We always have to use 9-digit notation for landline numbers. Since we always have a 9-digit entry, otherwise we cannot make calls, no number transformation is needed.
Looking at it from a different angle, if you even had a 7-digit record in CardDAV, do you know what local zone this number applies to?
After all, you can't treat it with a machine parser, because maybe they are numbers from different zones. You do not know this, so we always save it in 9 digits. There is nothing to do with the numbers from CardDAV, unless you want to tidy up and save internationally +48.
Worse still, the value area can't be empty, if it could be empty then I would leave it like that.

Unfortunately not an option (by design). You need to configure your local area code within [location].
You need to set [location] areaPrefix = ""
I set areaPrefix = "" but I can't set area to a blank field.

You see, I have 9 digitally stored mobile and landline numbers, they cannot be changed from the machine because they are stored correctly in CardDAV without the need to modify them. I can't get this in l2cpbg.
I want to transfer the numbers to LDAP as they are stored in CardDAV.
despite being set:
areaPrefix = ""
maxarealenght = 9
area = 68
When you enter complete 9-digit numbers from CardDAV, the transformation is performed and area is added, whatever I put in area will be added to the number.

In my case, I cannot get the situation that the telephone number from CardDAV is 1 to 1 transferred to LDAP.

Additionally, I cannot configure any external LDAP client to work with l2cpbg. I have tried loads of programs and I have trouble connecting everywhere.
Today I can only judge 0/1 if UCM is downloading data from l2cpbg, but when it is not collecting it I don't see why. Can you tell me which LDAP client you are using with l2cpbg?
But I already wrote it and I think you also configured it the right way as well as you dropped your old l2cpbg database.

I also hope that I have configured everything well :-)
Although I've tried so many options and combinations that I'm already stupid myself.

I expect another failure of mine.

I'll do some more testing to find out whats wrong.

In my opinion, you should treat landline numbers (classic phones) differently than mobile numbers. For landline (classic) telephone numbers, the transformations you have designed should follow. However, for cell numbers you either do not make any transformations or define them separately, rather for adding the international prefix (00 or +).

Regarding https://en.wikipedia.org/wiki/Telephone_numbers_in_Poland Poland has a very easy and simple phone number assignment. And according to that description I don't see a logical difference between a landline or mobile phone number assignments.
What's different between landline and mobile number assignments (I don't see)?

Of course, you are right, this numbering is no different, here and here we have 9 digits.
Only l2cpbg does the area transformation with no number type distinction.
And yet such a transformation should not be performed for cell numbers, because there are no prefixes, locations, etc. These numbers are global.
If I had the option to disable the transformation for cellular numbers in l2cpbg, I would stop bothering you :-)

For me, the best (fastest) option would be to turn off transformation on phone numbers.

Let me do some debugging first.

Probably my combination is that I have to send this mobile number to UCM as the main number because it is an obligatory field and I have mobile numbers everywhere in Radiclae.

I'm unfortunately not aware of UCM. Might also be that UCM changes the request in a way I don't handle correctly.

I don't think UCM changes what it gets.

I'll build some test cases and do some sample ldapsearch'es on weekend. We'll get it! ;-)

I count on it very much. Thank you for your great support and involvement in such an unusual problem with which I came.
I am of good cheer. If you have tasks for me to verify or test, don't wait!
Just give me a hint with LDAP client, it will be much easier for me.

Actions

Copy link

Updated by Pawel Wasylewicz about 3 years ago

Joerg,

ldapsearch helped a lot, I feel stupid that I didn't use it myself before, I was looking for a software for Windows ....

You do everything right with the numbers.

UCM has a problem with spaces after formatting numbers.

If I set the area to 7, you format the numbers in 3 digit groups, separating them with spaces. If I give area 9, you add a prefix and do not add spaces and this number goes to UCM.

Can you add a switch excluding number formatting (adding spaces)?

This will solve my problem entirely.

Paul

Actions

Copy link

Updated by Jörg Ebeling about 3 years ago

Paul,

great news!

Pawel Wasylewicz wrote in #note-8:

Joerg,

ldapsearch helped a lot, I feel stupid that I didn't use it myself before, I was looking for a software for Windows ....

No reason to feel stupid. I don't like ldapsearch very much because of it's complicated syntax, but once you find the correct syntax it's awful helpful ;-)

UCM has a problem with spaces after formatting numbers.

Oh, that's ugly...

If I set the area to 7, you format the numbers in 3 digit groups, separating them with spaces. If I give area 9, you add a prefix and do not add spaces and this number goes to UCM.

It's not me who's doing that kind of grouping. It's an impressive worldwide used library from Google. It has some kind of "prettify" function which make a number better readable for humans. In the normal use-case, a directly attached telephone, it's very helpful to see the number in group of numbers.
I guess the reason why the spaces go away with the wrong maxarealength = 9 is, that it's wrong ;-) ... and the prettifier function fail with a non-prettified result.

Can you add a switch excluding number formatting (adding spaces)?

Yes, should be easy possible.

But please keep in mind that the Polish number composition is:

2 digit international code (optional)
2 digit area or mobile code
7 local area digits (the number is unique within that area)

At the end you have to set maxarealength = 7.

Actions

Copy link

#10

Updated by Jörg Ebeling about 3 years ago

File l2cpbg-0.9.1-beta-5_linux-amd64.tgz l2cpbg-0.9.1-beta-5_linux-amd64.tgz added

Hi Paul,

attached to this ticket, please try beta5, but before please add the following switch:

[location]
  # Number prettifier: By default phone numbers loaded from CardDAV get
  # prettified in two ways. At first, if a CardDAV number is stored in
  # international format, but you live in the same country, the international
  # part get removed. At second, the number get formatted in (spaced or braced)
  # number groups as it's common for your country.
  # You can disable this prettifying here by setting the value to false.
  prettifyNums = false

But I worry it's not the best way.
I think it would be better to implement some kind of "space remover" function cause: Imagine you've some phone numbers with spaces within your CardDAV addresses. Those would still fail.

Actions

Copy link

#11