Hi, I'm a client of a provider of ThirdLane PBX Manager Multi Tenant using SPA504G phones.
How do I set up the phones so that they dynamically pull a list of valid extensions out of Asterisk/PBX Manager so that people can browse the directory on the phone for Internal Calls or Transfers?
Thanks,
Dom
Dynamic Extention Directory in Phone
These SIP phones support LDAP so that isn't a problem, but it still means we need to run a separate service for Directory Lookups that will need to be manually updated every time we update the PBX.
The Phones are Authenticated to the PBX via SIP. It would make sense to authenticate to a built in LDAP server based on the SIP login and that this should all be provided by Asterisk/PBX Manager and dynamically updated based on the Directory in PBX Manager.
Lets take devils advocate
Lets take devils advocate approach here. How would you feel if I were on your same MTE, and downloaded your entire company directory and started telemarketing and spamming the crap out of you? There is nothing in the openldap design that appears to allow complete compartmentalization. Once I have read-access to the directory it doesn't make a difference if you are tenant=titsmuggler or tenant=assmunch; I can read everyone's contact information. To take this risk to an even higher state, I can learn what other companies the parent hosting company has for customers. Perhaps I could be so inclined as to solicit them to use a competing hosted pbx services from this list. Additionally, due to the nature of many phones, not only would you see all of your contacts, but you would end up having to sort through a list of all the other contacts too (the directory objects are generically defined and causes everyone to be stuck in one giant group). We try not to take a microsoft approach to features (ie. create a feature first without the first damn concern over privacy or how it could be exploited) when we evaluate a potential feature. I would definitely love to see something like this written, it would help me stick more 'unified communication' tags on my products.
Ultimately a solution will take someone with extensive ldap programming knowledge to write an API that makes the phone think its speaking to an LDAP server, but really its talking to middleware that is perhaps pulling entries out of an SQL database or something else.
Until such time should you want a feature where changes to an extension automatically update an LDAP directory, you would need to buy your own single-tenant edition and use the 'event hooks' section of code to write changes to your personal LDAP server. Its a crude mechanism but it could be made to work.
As far as I can see Asterisk
As far as I can see Asterisk doesn't provide any Directory service, any features along these lines are provided by PBX Manager.
LDAP has OUs to define Organisational Units and it would be little work for TL to integrate an Authenticating LDAP server into PBX Manager that maps authenticated users to a tenant based OU as their root (instead of the LDAP base as their root). (Similar to FTP Home Directories)
None of this seems very difficult, it just needs a programmer, a few weeks, some imagination and can do attitude.
if you want to work on it,
if you want to work on it, I'll work with you. You'll need to put together a mockup to illustrate separate organizational units and show that queries cannot be done to dump the whole database. it will need to be tested with all the major players (ie phone manufacturers, the cisco spa's, snom, polycom, aastra etc)
Hmm, what exactly is covered
Hmm, what exactly is covered under the terms "I'll work with you"?
I'm a network administrator who has a few customers with Faktortel who use PBX Manager. The customers would like a directory on their phone and I'm not interested in maintaining it manually.
I'm not a programmer and I'm not necessarily interested in paying for the development that I can't on-charge to my customers, who are all paying monthly bills to Faktortel for the service.
it means that if you can
it means that if you can provide a working example of openldap where you have created fake tenants with contacts separated into different OUs; and from this working example I can log in with a credential and such credential is limited to the one company (meaning there is no way that credential will let me dump the whole directory of all contacts) and yet allow a completely seperate login credential allow likewise limitations of their company; I will take this information and make it a full-on campaign to get it incorporated into thirdlane as a complete replacement for the current 'company directory' system.
there would be no charge to you. your only expense would be the labor of creating this working example. I have so far not been successful at meeting these requirements with the testing performed sofar.
Before I spend too much of my
Before I spend too much of my time trying to figure out how to configure Open LDAP, the documentation has a very extensive chapter on Access Control:
http://www.openldap.org/doc/admin24/access-control.html
I'm not knowledgeable enough in LDAP to understand it properly in a precursory glance, but it seems to cover security definitions allowing users to be grouped, and defining what part of the tree they can query.
Assuming a tree of:
ou=TenantID,dn=ServerName,dn=Domain,dn=DomainSuffix
Perhaps the following authentication config:
access to dn.subtree="ou=TenantID,dn=ServerName,dn=Domain,dn=DomainSuffix"
by self write
by dn.subtree="ou=TenantID,dn=ServerName,dn=Domain,dn=DomainSuffix" read
not every sip phone works in the same manner. I cannot attest to those linksys/cisco SPA phones but some phones support LDAP lookups. Some phones require the purchase of add-on software to do this. the nature of LDAP, there is no secure way to run an LDAP server on a multi-tenant platform without making it possible for any person to download a employee/contact list of anyone on the MTE box. What is possible is to use the LDAP features of your phones to pull a list from a private LDAP server like ActiveDirectory that belongs to the tenant.