Publishing feature codes to LDAP client?

[Michael Mol]

Something I'd like to be able to do, but I don't know if Bluebox has the
capability to do it easily or cleanly.

So, I need to set up feature codes. For my first pass at deployment,
I'll be using Ekiga as a softphone client, and Ekiga supports LDAP
directories for address books...and it would be really, really cool if I
could have feature codes automatically available to them via this
mechanism as I add them.

(In fact, it would be really, really cool if I could list all the
numbers a device has access to in the same way...)

Is this a supported behavior? Is there an established way to do it?

[Darren Schreiber]

No LDAP support I'm afraid. though I'm not even sure I understand the
request. What is the relation between "feature codes" and LDAP? The two
seem like unrelated concepts.

[Michael Mol]

A feature code is, of course, a number a user dials to trigger a feature
within the system.

For me, it would be convenient for these numbers to present themselves
in the user's address book on their device. (Ekiga, in my case.)

The easiest way to accomplish that (in my case) would be to publish the
list of feature codes as/in an LDAP directory.

Does that help?

[Darren Schreiber]

Not really.

Feature codes are fairly static - the advantage of LDAP integration is, in
my eyes, really that you have a directory which changes over time (new
employees join, employees leave, etc.) and the integration allows the
updates to happen automatically so a sysadmin sets up a new user or
deletes a user and their phone comes/goes with it.

What you're proposing is to take something that never changes and feed it
through LDAP. I don't understand the point. You just don't want to enter
*72 one time into the LDAP directory that Ekiga connects to? If that's the
case then I guess I do get it but sounds pretty low-priority to me...

[Michael Mol]

The advantage for me is in provisioning of new extensions and devices; I
don't have to manually add a few feature codes to each client
configuration every time I add a new client. LDAP is quite literally the
only remote directory system supported by Ekiga. If I only have to add
two pieces of configuration--an account and a remote address book,
that's better than five (an account and four feature codes/well-known
numbers).

Anyway, if you don't find that useful...I suppose that's your
prerogative. I only intended to ask if the feature was there, not
attempt to justify its use case. There are certainly other theoretical
ways of handling it (Having bluebox pull data from an LDAP server,
having something else pull from MySQL and populate an LDAP server, have
a script autoconfigure ekiga on first login, etc), but none of those are
easily attainable within any kind of anticipated time frame.

Now, I would _also_ love to be able to have the various numbers the
device has access to (based on contexts, I imagine) to appear
automagically in an LDAP directory the device can read from. Having
feature codes appear via that mechanism seems conceptually trivial.
(Though you may need to filter out pattern-based routes, if those would
leak into such a directory.)

[Darren Schreiber]

Hi Michael,
My critique of the request was more because it would seem like I am
missing the point. Now that you're explaining this more, I'm wondering if
you are asking for us to provide the full LDAP service when you say "LDAP
integration"? Normally when people ask for LDAP integration they mean "I
want blue.box to push/retrieve data from my existing LDAP server." Maybe
what you are saying is "I want blue.box to offer LDAP services to the
Ekiga softphone directly, which would include a directory and all feature
codes." Is that the request?

That would strike me as more useful. However, it's a lot of work, and I
think higher priorities right now are simplifying the blue.box install and
management process frankly, based on what we've heard as feedback from
existing users. So that's probably going to happen first. Specifically
people continue to be confused by contexts and how to setup routes. So
we're going to fix that. You are certainly welcome to contribute an LDAP
module in the meantime. The feature does not currently exist, though.

I am happy to help you figure out where to look for the data in the
database if you want to build an LDAP integration module and even help
debug it/etc. if you're interested.

[Michael Mol]

On 05/16/2013 11:16 AM, Darren Schreiber wrote:
> Hi Michael,
> My critique of the request was more because it would seem like I am
> missing the point. Now that you're explaining this more, I'm wondering if
> you are asking for us to provide the full LDAP service when you say "LDAP
> integration"? Normally when people ask for LDAP integration they mean "I
> want blue.box to push/retrieve data from my existing LDAP server." Maybe
> what you are saying is "I want blue.box to offer LDAP services to the
> Ekiga softphone directly, which would include a directory and all feature
> codes." Is that the request?

Pretty much. The way I see it, there's a lot of power potential of
customizing LDAP views per-device. (Well, per-context, where the
per-device view would be based on a merging of the contexts it exists
within, if I understand contexts correctly.)

If blue.box can push this kind of data automagically into an existing
LDAP server, that'd work too.

>
> That would strike me as more useful. However, it's a lot of work, and I
> think higher priorities right now are simplifying the blue.box install and
> management process frankly, based on what we've heard as feedback from
> existing users.

Absolutely.

> So that's probably going to happen first. Specifically
> people continue to be confused by contexts and how to setup routes. So
> we're going to fix that. You are certainly welcome to contribute an LDAP
> module in the meantime. The feature does not currently exist, though.

Understood.

>
> I am happy to help you figure out where to look for the data in the
> database if you want to build an LDAP integration module and even help
> debug it/etc. if you're interested.

I'd love to, but I'm overcommitted on time by a ridiculous amount right
now. For it to happen, my employer would need to see a value to using it
over, e.g. pulling data and routes from Active Directory (Though there'd
be an impedance mismatch there, too; I imagine.).

Thanks for the information.

[snip]