Nice that you succeed with Thunderbird, I never tried that (because my TB can't make phone calls )
Well, I didn't used Linphone for a couple of years, but just did a quick view to their feature list.
Couldn't find any point stating that they support LDAP PhoneBook lookups in any case?!
Do you know if they support LDAP PhoneBook lookups? And if "yes" isn't it working?
Thunderbird was just for testing purpose because it was the first client that came to my mind and was already running. btw: you can let TB dial numbers for on any softphone/hardphone.
Yes, Linphone already has LDAP-support built in. Anfter Thunderbird it was directly the second client I was testing. I successfully tested it with some random LDAP test server (ldap://ldap.forumsys.com) and it worked too, but I didn't get it running with your server yet.
In my point of view it should work even without patching you software because LDAP is like a standard, or? Maybe I have just setup the credentials wrong....
Yes, in my point of view it should also work, but the LDAP-Server implementation of my L2CPBG isn't a fully-fledged LDAP Server. Instead of I only implemented the generic functionality which was required by the already supported phones. In the moment where an LDAP-Client request something which isn't implemented, it may fail.
Luckily Linphone is freely available as well as open source. So it should be easy implementable without hacking around
Today I did some quick tests, and even if I tested with an early L2CPBG 0.9.8.dev version, I'm pretty sure that it will also work with the current 0.9.7 release.
Please see the following example Linphone config:
"Server-URL" has to become your L2CPBG's hostname or IP, and Port
"Bindungs-DN" as well as "Passwort" also the ones from your L2CPBG config
"TLS..." has to be off
"Suchbasis" again your L2CPBG's "[ldap] base" setting
This worked in my first quick test, but there are some issues.
Linphone's LDAP implementation look somehow uncommon to me
They do not differ between a (forward) "name" and a (reverse) "number" lookup. That why the "Filter" entry is that large
It looks like they use the "Namensattribute" field as "first found get displayed" field, instead of a concatenation list
Similar uncommon behavior with "SIP-Attribute"
Normally a phone will show you from an LDAP contact multiple fields to identify a contact. I.e. Name + Company, as well as one contact might have multiple phone numbers like homePhone, telephoneNumber (workPhone), mobile, ...
But with the listed issues from 1.-3. they seem to display one entry per phone number in a way you can't differ between them.
Updated by 
Updated by 