LDAP to CardDav (1 way read) Phone Book Gateway

[JEBs]

Hi folks,

I'm using FusionPBX since a couple of months and (nearly) everything works like a charm.
But: I've been a little unhappy with the phone-directory integration (same as with other products like Asterisk, Ansitel, Fritz!Box).

So it's not FusionPBX related! It's my uncommon scenario not having an LDAP company directory. Instead off, me and my company is based on CardDAV Adressbooks (like Nextcloud, Owncloud and the like). So it was required to convert my CardDAV address books to a phone readable format every couple of weeks.
Sometime I was tired about it and after checking Google without useful results, I decided to write some kind of Gateway so that this stupid work ends.
It's now working (but beta) and I'm happy having it since some weeks.

It's "evil" close-source / binary-only , cause I plan to sell it to a couple of my customers which have a similar environment, but it's freely usable up to approx. 12 requests per hour.

If someone is interested in, please check https://projects.shbe.net/projects/l2cpbg for further infos (as well as the binaries).

Would be cool to get some feedback how useless it is!

 

[John]

Hi @JEBs ,

Does it automatically sign into CardDav accounts and import them into Fusion? Did I understand this correctly? I am interested in something like this and what would be your pricing?

 

[JEBs]

Hi @John,

no, my "LDAP to CardDAV phone book gateway" is fully separate from FusionPBX because I required a solution also usable for Yeastar and other (Asterisk based) PBXes.

It use (requires) the LDAP PhoneBook functionality of your Phone (Grandstream, Snom, Yealink, ...), completely alongside of FusionPBX.
For sure, this also means that it does not know about FusionPBX- stored numbers or extensions (in my use cases the number of PBX- Extensions was always a fraction of external CardDAV stored numbers, thus I maintain this fraction of extension numbers also in my (CardDAV) contacts).

Please check the last paragraph of "Use Case" @ https://projects.shbe.net/projects/l2cpbg/wiki/Contents which I think describe the functionality best.

Price?!
I planned to sell it only for companies. That's why I made this "12 free requests per hour" limitation from which I thought this is massive enough for personal usage... and after these 12 Req/h it doesn't stop working. Instead of it give you only a small hint that you reached this limit.
Well, to be honest... even the two companies from which I know that they use my Gateway, still use the "free" version.
So I guess you'll also go fine with the free version .

 

[John]

Thank you @JEBs for your quick reply. This is my understanding from what I read.

Gets the CardDav contacts -> Converts them to LDAP -> Makes it available for Desktop Phone Requests -> Desktop Phones can send a request and download the contacts from it

Is there any authentication, or it is open to requests from anyone?

Cheers,

John

 

[JEBs]

Hi John,

yes, in principle it work this way.

And one more "yes": For sure there is an authentication requirement so it's not open for anyone .

1.) You've to tell the Gateway a CardDav's Login/Password so that it can collect the contacts:

#
# Your CardDAV server where this Gateway get the contacts from
#
[dav]
server = "https://cloudserver.example.com/remote.php/dav"
user = "cloud-login-name"
pass = "cloud-login-password"

I prefer to use a separate Gateway-Account to whom I share the relevant AddressBooks.

2.) You have to define Login/Auth Permissions within the Gateway how the Desktop-Phones have to authorize:

#
# The Gateway will act as LDAP Server, listening
# for requests from your phone(s).
#
[ldap]
host = "0.0.0.0"
#port = 1389
base = "dc=example, dc=com"

[ldap.bind]
dn = "cn=pbx"
pass = "your-password"

Without the [ldap.bind] defined values, nobody can access the contacts from the Gateway. But there's a small limitation:
The internal LDAP Server doesn't support LDAPS (encrypted LDAP communication) at the moment. Therefore the Gateway should not be used in an untrusted network!

 

[John]

Thank you very much @JEBs for your detailed explanation. It is very kind of you.