L2CPBG

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

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.

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

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.

It works, it works, it works :-)

I'm cleaning up CardDAV.

I wonder if UCM will correctly search or refresh the list from external LDAP. This is what I have to test and torture Grandstream!

Thank you!

Yes, UCM builds its own address book from extensions.

To tell the truth, I don't know how it all will behave together.

I just managed to get it started :-)

Maybe I will switch entirely to L2CPBG.

I have to test.

Thank you!
Paul