First of all- Amazing project. Tired of asterisk deadlocking all the time we have been deploying asterisk with OpenSER as the registrar. Freeswitch is a huge relief! This is an extremely important feature we have been looking for. Asterisk realtime ldap integration is very flaky. I found this page: http://wiki.freeswitch.org/wiki/FreeSwitch_Dialplan_Directory But there are no clues as to the schema, the queries generated and what exactly it can hold in Ldap. I am also curious to know whether sofia's sip registrations, gateways etc can be kept in LDAP. We are basically developing an extensive plugin based control panel and a Asterisk module is already ready. However, we are writing asterisk .conf files for managing asterisk. We would be quite pleased to develop a FreeSwitch Ldap plugin to manage users,sip gateways, groups, features, etc. Though the XML configuration file is extremely easy to parse and write, pure LDAP integration would be amazing. Any pointers on this would be appreciated. -- Faraz R Khan Chief Architect Emergen Consulting Pvt Ltd +92.21.529.0381 x200 www.emergen.biz
Currently the directory interface is only used for that dialplan, I would like to enhance that in the future. The directory dialploan uses a filter of exten=destination number, and then has name/value pairs, I will see if I can find the schema we used back when we developed it, short of that, the code is the best reference on that. Another option is to use mod_xml_curl and have your cgi back end to ldap of your choice. This will give you more flexibility to use other caller information in your ldap lookup. Mike On May 28, 2008, at 1:58 AM, Faraz R. Khan wrote:
First of all- Amazing project. Tired of asterisk deadlocking all the time we have been deploying asterisk with OpenSER as the registrar. Freeswitch is a huge relief!
This is an extremely important feature we have been looking for. Asterisk realtime ldap integration is very flaky. I found this page:
http://wiki.freeswitch.org/wiki/FreeSwitch_Dialplan_Directory
But there are no clues as to the schema, the queries generated and what exactly it can hold in Ldap. I am also curious to know whether sofia's sip registrations, gateways etc can be kept in LDAP.
We are basically developing an extensive plugin based control panel and a Asterisk module is already ready. However, we are writing asterisk .conf files for managing asterisk. We would be quite pleased to develop a FreeSwitch Ldap plugin to manage users,sip gateways, groups, features, etc.
Though the XML configuration file is extremely easy to parse and write, pure LDAP integration would be amazing. Any pointers on this would be appreciated.
-- Faraz R Khan Chief Architect Emergen Consulting Pvt Ltd +92.21.529.0381 x200 www.emergen.biz
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
We have a concept called the "directory interface" not to be confused with the "user directory". The directory interface is a pluggable abstract API that looks and feels like LDAP only you can plug in anything you want to implement the functions. mod_ldap is a module that registers to this interface and connects LDAP to it. So essentially you load mod_ldap then you use the freeswitch directory interface as you would have used the ldap code and it will carry over. There is a mod_dialplan_directory who uses the directory interface to ask for a dialplan, and installs the results into an extension. In the case of mod_ldap obviously it allows you to get your dialplan from LDAP. Now also in mod_ldap, there is some code someone recently contributed to tie our XML interface to LDAP, This is more interesting because then when anything in FreeSWITCH tries to lookup a user, dialplan entry or anything else in our XML config, all the important details are passed to LDAP where it can make a query, pull the info out of LDAP and deliver it back to FreeSWITCH as the XML it was looking for. This allows you to make all of the registrations, dialplan etc real time driven by LDAP, you can also bind a perl or lua script to this operation as well as mod_xml_curl who will turn the request into an HTTP post to a web server to fetch the data. On Wed, May 28, 2008 at 8:09 AM, Michael Jerris <mike@jerris.com> wrote:
Currently the directory interface is only used for that dialplan, I would like to enhance that in the future. The directory dialploan uses a filter of exten=destination number, and then has name/value pairs, I will see if I can find the schema we used back when we developed it, short of that, the code is the best reference on that. Another option is to use mod_xml_curl and have your cgi back end to ldap of your choice. This will give you more flexibility to use other caller information in your ldap lookup.
Mike
On May 28, 2008, at 1:58 AM, Faraz R. Khan wrote:
First of all- Amazing project. Tired of asterisk deadlocking all the time we have been deploying asterisk with OpenSER as the registrar. Freeswitch is a huge relief!
This is an extremely important feature we have been looking for. Asterisk realtime ldap integration is very flaky. I found this page:
http://wiki.freeswitch.org/wiki/FreeSwitch_Dialplan_Directory
But there are no clues as to the schema, the queries generated and what exactly it can hold in Ldap. I am also curious to know whether sofia's sip registrations, gateways etc can be kept in LDAP.
We are basically developing an extensive plugin based control panel and a Asterisk module is already ready. However, we are writing asterisk .conf files for managing asterisk. We would be quite pleased to develop a FreeSwitch Ldap plugin to manage users,sip gateways, groups, features, etc.
Though the XML configuration file is extremely easy to parse and write, pure LDAP integration would be amazing. Any pointers on this would be appreciated.
-- Faraz R Khan Chief Architect Emergen Consulting Pvt Ltd +92.21.529.0381 x200 www.emergen.biz
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
At one point I was very interested in this...then I got a job. =[ I thought mod_ldap was more of a PoC than anything. It might work (I couldn't get it working and unfortunately don't remember exactly why..) but there really isn't much point. I would have to do at least 5 ldap queries (if not more) to get the most of the same functionality as the XML dialplan. Also, the elegance of stackable functionality in the XML dialplan is hard to imitate, at least with the any amount of efficiency. If you don't need to stack actions a regular expression will almost certainly be better. Attached is the schema, config, and sample ldif I used to get the xml stuff working. With a little effort it could work with an existing schema (possibly the ITU recomended LDAP schema that ser uses). I am not sure how easy it would be to get the same flexibility as key/value pairs (like the FS xml uses) though. -John Anthony Minessale wrote:
We have a concept called the "directory interface" not to be confused with the "user directory". The directory interface is a pluggable abstract API that looks and feels like LDAP only you can plug in anything you want to implement the functions.
mod_ldap is a module that registers to this interface and connects LDAP to it. So essentially you load mod_ldap then you use the freeswitch directory interface as you would have used the ldap code and it will carry over.
There is a mod_dialplan_directory who uses the directory interface to ask for a dialplan, and installs the results into an extension. In the case of mod_ldap obviously it allows you to get your dialplan from LDAP.
Now also in mod_ldap, there is some code someone recently contributed to tie our XML interface to LDAP, This is more interesting because then when anything in FreeSWITCH tries to lookup a user, dialplan entry or anything else in our XML config, all the important details are passed to LDAP where it can make a query, pull the info out of LDAP and deliver it back to FreeSWITCH as the XML it was looking for. This allows you to make all of the registrations, dialplan etc real time driven by LDAP, you can also bind a perl or lua script to this operation as well as mod_xml_curl who will turn the request into an HTTP post to a web server to fetch the data.
On Wed, May 28, 2008 at 8:09 AM, Michael Jerris <mike@jerris.com <mailto:mike@jerris.com>> wrote:
Currently the directory interface is only used for that dialplan, I would like to enhance that in the future. The directory dialploan uses a filter of exten=destination number, and then has name/value pairs, I will see if I can find the schema we used back when we developed it, short of that, the code is the best reference on that. Another option is to use mod_xml_curl and have your cgi back end to ldap of your choice. This will give you more flexibility to use other caller information in your ldap lookup.
Mike
On May 28, 2008, at 1:58 AM, Faraz R. Khan wrote:
> First of all- Amazing project. Tired of asterisk deadlocking all the > time we have been deploying asterisk with OpenSER as the registrar. > Freeswitch is a huge relief! > > This is an extremely important feature we have been looking for. > Asterisk realtime ldap integration is very flaky. I found this page: > > http://wiki.freeswitch.org/wiki/FreeSwitch_Dialplan_Directory > > But there are no clues as to the schema, the queries generated and > what > exactly it can hold in Ldap. I am also curious to know whether sofia's > sip registrations, gateways etc can be kept in LDAP. > > We are basically developing an extensive plugin based control panel > and > a Asterisk module is already ready. However, we are writing > asterisk .conf files for managing asterisk. We would be quite > pleased to > develop a FreeSwitch Ldap plugin to manage users,sip gateways, groups, > features, etc. > > Though the XML configuration file is extremely easy to parse and > write, > pure LDAP integration would be amazing. Any pointers on this would be > appreciated. > > > -- > Faraz R Khan > Chief Architect > Emergen Consulting Pvt Ltd > +92.21.529.0381 x200 > www.emergen.biz <http://www.emergen.biz> > > > _______________________________________________ > Freeswitch-users mailing list > Freeswitch-users@lists.freeswitch.org <mailto:Freeswitch-users@lists.freeswitch.org> > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users > http://www.freeswitch.org
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org <mailto:Freeswitch-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/
AIM: anthm MSN:anthony_minessale@hotmail.com <mailto:MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com <mailto:PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <mailto:sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 <http://iax:guest@conference.freeswitch.org/888> googletalk:conf+888@conference.freeswitch.org <mailto:googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
------------------------------------------------------------------------
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
dn: cn=1000,ou=192.168.0.102,o=galacticbell,dc=galacticbell,dc=com objectClass: top objectClass: sipCred objectClass: inetOrgPerson cn: 1000 sn: 1000 idname: 1000 param: password param: vm-password paramvalue: 1234 paramvalue: 0000 variable: accountcode variablevalue: 1000 attributetype ( 1.3.6.1.4.1.65535.1 NAME 'Reserved' DESC 'Reserved attribute' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) attributetype ( 1.3.6.1.4.1.65535.2.1.1 NAME 'FSname' DESC 'exten FSname import from exten name= in xml' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) attributetype ( 1.3.6.1.4.1.65535.2.1.2 NAME 'exten' DESC 'exten number' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributetype ( 1.3.6.1.4.1.65535.2.1.3 NAME 'application' DESC 'action for exten' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributetype ( 1.3.6.1.4.1.65535.2.1.4 NAME 'data' DESC 'argument to application' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributetype ( 1.3.6.1.4.1.65535.2.1.53 NAME 'field' DESC 'target for regular expression' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributetype ( 1.3.6.1.4.1.65535.2.1.6 NAME 'expression' DESC 'regular expression to matich in field' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributetype ( 1.3.6.1.4.1.65535.2.1.7 NAME 'regex' DESC 'BOOL if true process regex' SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 ) attributetype ( 1.3.6.1.4.1.65535.3.1.1 NAME 'context' DESC 'context of exten' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) objectclass ( 1.3.6.1.4.1.65535.3.2.1 NAME 'contextObject' SUP top AUXILIARY DESC 'Context' MUST ( context ) ) objectclass ( 1.3.6.1.4.1.65535.2.2.2 NAME 'extenObject' SUP top AUXILIARY DESC 'exten object' MUST ( FSname $ exten $ application $ data ) MAY ( regex $ expression $ field ) ) attributetype ( 1.3.6.1.4.1.65535.4.1.1 NAME 'FShost' DESC 'BOOL if true process regex' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributetype ( 1.3.6.1.4.1.65535.4.1.2 NAME 'section' DESC 'BOOL if true process regex' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributetype ( 1.3.6.1.4.1.65535.4.1.3 NAME 'tag' DESC 'BOOL if true process regex' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributetype ( 1.3.6.1.4.1.65535.4.1.4 NAME 'idname' DESC 'BOOL if true process regex' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributetype ( 1.3.6.1.4.1.65535.4.1.5 NAME 'param' DESC 'BOOL if true process regex' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributetype ( 1.3.6.1.4.1.65535.4.1.6 NAME 'paramvalue' DESC 'BOOL if true process regex' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributetype ( 1.3.6.1.4.1.65535.4.1.7 NAME 'variable' DESC 'BOOL if true process regex' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributetype ( 1.3.6.1.4.1.65535.4.1.8 NAME 'variablevalue' EQUALITY caseIgnoreIA5Match DESC 'BOOL if true process regex' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) objectclass ( 1.3.6.1.4.1.65535.4.2.1 NAME 'sipCred' SUP top AUXILIARY DESC 'sip object' MUST ( idname $ param $ paramvalue ) MAY ( variable $ variablevalue ) ) objectclass ( 1.3.6.1.4.1.65535.4.2.2 NAME 'fsDirectory' SUP top AUXILIARY DESC 'fs object' MUST ( idname ) MAY ( tag $ section $ FShost ) )
Thanks a lot. I intend to use it mostly as a SIP user directory. For the dial-plan I dont mind parsing and syncing XML file across servers (if there were a small cluster). The main deal is AUTHENTICATION. The authentication scheme I wish to keep is Kerberos (with SASL in Ldap for binding). This way all my credentials are centralized, be it SIP or mail. This would be a great achievement for me and many enterprises having thousands of identities. The dialplan stays fairly static once developed so I dont mind that being in a XML file. The dynamic stuff (user credentials) I wish to keep in a centralized store such as LDAP. On Wed, 2008-05-28 at 20:12 -0500, John Skopis (Lists) wrote:
At one point I was very interested in this...then I got a job. =[
I thought mod_ldap was more of a PoC than anything. It might work (I couldn't get it working and unfortunately don't remember exactly why..) but there really isn't much point. I would have to do at least 5 ldap queries (if not more) to get the most of the same functionality as the XML dialplan. Also, the elegance of stackable functionality in the XML dialplan is hard to imitate, at least with the any amount of efficiency. If you don't need to stack actions a regular expression will almost certainly be better.
Attached is the schema, config, and sample ldif I used to get the xml stuff working.
With a little effort it could work with an existing schema (possibly the ITU recomended LDAP schema that ser uses). I am not sure how easy it would be to get the same flexibility as key/value pairs (like the FS xml uses) though.
-John
Anthony Minessale wrote:
We have a concept called the "directory interface" not to be confused with the "user directory". The directory interface is a pluggable abstract API that looks and feels like LDAP only you can plug in anything you want to implement the functions.
mod_ldap is a module that registers to this interface and connects LDAP to it. So essentially you load mod_ldap then you use the freeswitch directory interface as you would have used the ldap code and it will carry over.
There is a mod_dialplan_directory who uses the directory interface to ask for a dialplan, and installs the results into an extension. In the case of mod_ldap obviously it allows you to get your dialplan from LDAP.
Now also in mod_ldap, there is some code someone recently contributed to tie our XML interface to LDAP, This is more interesting because then when anything in FreeSWITCH tries to lookup a user, dialplan entry or anything else in our XML config, all the important details are passed to LDAP where it can make a query, pull the info out of LDAP and deliver it back to FreeSWITCH as the XML it was looking for. This allows you to make all of the registrations, dialplan etc real time driven by LDAP, you can also bind a perl or lua script to this operation as well as mod_xml_curl who will turn the request into an HTTP post to a web server to fetch the data.
On Wed, May 28, 2008 at 8:09 AM, Michael Jerris <mike@jerris.com <mailto:mike@jerris.com>> wrote:
Currently the directory interface is only used for that dialplan, I would like to enhance that in the future. The directory dialploan uses a filter of exten=destination number, and then has name/value pairs, I will see if I can find the schema we used back when we developed it, short of that, the code is the best reference on that. Another option is to use mod_xml_curl and have your cgi back end to ldap of your choice. This will give you more flexibility to use other caller information in your ldap lookup.
Mike
On May 28, 2008, at 1:58 AM, Faraz R. Khan wrote:
> First of all- Amazing project. Tired of asterisk deadlocking all the > time we have been deploying asterisk with OpenSER as the registrar. > Freeswitch is a huge relief! > > This is an extremely important feature we have been looking for. > Asterisk realtime ldap integration is very flaky. I found this page: > > http://wiki.freeswitch.org/wiki/FreeSwitch_Dialplan_Directory > > But there are no clues as to the schema, the queries generated and > what > exactly it can hold in Ldap. I am also curious to know whether sofia's > sip registrations, gateways etc can be kept in LDAP. > > We are basically developing an extensive plugin based control panel > and > a Asterisk module is already ready. However, we are writing > asterisk .conf files for managing asterisk. We would be quite > pleased to > develop a FreeSwitch Ldap plugin to manage users,sip gateways, groups, > features, etc. > > Though the XML configuration file is extremely easy to parse and > write, > pure LDAP integration would be amazing. Any pointers on this would be > appreciated. > > > -- > Faraz R Khan > Chief Architect > Emergen Consulting Pvt Ltd > +92.21.529.0381 x200 > www.emergen.biz <http://www.emergen.biz> > > > _______________________________________________ > Freeswitch-users mailing list > Freeswitch-users@lists.freeswitch.org <mailto:Freeswitch-users@lists.freeswitch.org> > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users > http://www.freeswitch.org
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org <mailto:Freeswitch-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/
AIM: anthm MSN:anthony_minessale@hotmail.com <mailto:MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com <mailto:PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <mailto:sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 <http://iax:guest@conference.freeswitch.org/888> googletalk:conf+888@conference.freeswitch.org <mailto:googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
------------------------------------------------------------------------
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
plain text document attachment (sample.ldif) dn: cn=1000,ou=192.168.0.102,o=galacticbell,dc=galacticbell,dc=com objectClass: top objectClass: sipCred objectClass: inetOrgPerson cn: 1000 sn: 1000 idname: 1000 param: password param: vm-password paramvalue: 1234 paramvalue: 0000 variable: accountcode variablevalue: 1000
plain text document attachment (garbageschema.schema) attributetype ( 1.3.6.1.4.1.65535.1 NAME 'Reserved' DESC 'Reserved attribute' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetype ( 1.3.6.1.4.1.65535.2.1.1 NAME 'FSname' DESC 'exten FSname import from exten name= in xml' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetype ( 1.3.6.1.4.1.65535.2.1.2 NAME 'exten' DESC 'exten number' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.65535.2.1.3 NAME 'application' DESC 'action for exten' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.65535.2.1.4 NAME 'data' DESC 'argument to application' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.65535.2.1.53 NAME 'field' DESC 'target for regular expression' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.65535.2.1.6 NAME 'expression' DESC 'regular expression to matich in field' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.65535.2.1.7 NAME 'regex' DESC 'BOOL if true process regex' SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 )
attributetype ( 1.3.6.1.4.1.65535.3.1.1 NAME 'context' DESC 'context of exten' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
objectclass ( 1.3.6.1.4.1.65535.3.2.1 NAME 'contextObject' SUP top AUXILIARY DESC 'Context' MUST ( context ) )
objectclass ( 1.3.6.1.4.1.65535.2.2.2 NAME 'extenObject' SUP top AUXILIARY DESC 'exten object' MUST ( FSname $ exten $ application $ data ) MAY ( regex $ expression $ field ) )
attributetype ( 1.3.6.1.4.1.65535.4.1.1 NAME 'FShost' DESC 'BOOL if true process regex' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.65535.4.1.2 NAME 'section' DESC 'BOOL if true process regex' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.65535.4.1.3 NAME 'tag' DESC 'BOOL if true process regex' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.65535.4.1.4 NAME 'idname' DESC 'BOOL if true process regex' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.65535.4.1.5 NAME 'param' DESC 'BOOL if true process regex' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.65535.4.1.6 NAME 'paramvalue' DESC 'BOOL if true process regex' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.65535.4.1.7 NAME 'variable' DESC 'BOOL if true process regex' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.65535.4.1.8 NAME 'variablevalue' EQUALITY caseIgnoreIA5Match DESC 'BOOL if true process regex' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
objectclass ( 1.3.6.1.4.1.65535.4.2.1 NAME 'sipCred' SUP top AUXILIARY DESC 'sip object' MUST ( idname $ param $ paramvalue ) MAY ( variable $ variablevalue ) )
objectclass ( 1.3.6.1.4.1.65535.4.2.2 NAME 'fsDirectory' SUP top AUXILIARY DESC 'fs object' MUST ( idname ) MAY ( tag $ section $ FShost ) )
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org -- Faraz R Khan Chief Architect Emergen Consulting Pvt Ltd +92.21.529.0381 x200 www.emergen.biz
Hi, I had some free time and decided to add sasl support to mod_xml_ldap. I only tested kerberos5 auth though. I also added support for search filters. The problem with the xml_ldap directory stuff is that since freeswitch never actually sends the hash (or cleartext password) to the module it can't bind as the extension to compare. I would have much rather registered a module as an authentication provider vs a xml provider. As I understand this portion of code is somewhere in between the core and mod_sofia so it would need to be done as an extension to mod_sofia. All it does is connect to ldap as a privileged user, search for a freeswitch extension, generate xml, and send the xml to fs. If I find some more free time I may add support for requested attrs in the ldap query. If you take a look at the code it currently grabs all attrs and then joins on key=keyval. I did this so ldap schema didn't have to be extended everytime the fs xml schema is extended. The reason would be rather than requesting 100 attrs and iterating through them all just request the ~4 required to generate the xml and iterate through them. Also startls/ssl support might be nice ;] -john PS Until someone adds the config to tree (I cant write the config file =\) here it is: http://rafb.net/p/A37tLo10.html Faraz R. Khan wrote:
Thanks a lot. I intend to use it mostly as a SIP user directory. For the dial-plan I dont mind parsing and syncing XML file across servers (if there were a small cluster). The main deal is AUTHENTICATION. The authentication scheme I wish to keep is Kerberos (with SASL in Ldap for binding). This way all my credentials are centralized, be it SIP or mail.
This would be a great achievement for me and many enterprises having thousands of identities. The dialplan stays fairly static once developed so I dont mind that being in a XML file. The dynamic stuff (user credentials) I wish to keep in a centralized store such as LDAP.
On Wed, 2008-05-28 at 20:12 -0500, John Skopis (Lists) wrote:
At one point I was very interested in this...then I got a job. =[
I thought mod_ldap was more of a PoC than anything. It might work (I couldn't get it working and unfortunately don't remember exactly why..) but there really isn't much point. I would have to do at least 5 ldap queries (if not more) to get the most of the same functionality as the XML dialplan. Also, the elegance of stackable functionality in the XML dialplan is hard to imitate, at least with the any amount of efficiency. If you don't need to stack actions a regular expression will almost certainly be better.
Attached is the schema, config, and sample ldif I used to get the xml stuff working.
With a little effort it could work with an existing schema (possibly the ITU recomended LDAP schema that ser uses). I am not sure how easy it would be to get the same flexibility as key/value pairs (like the FS xml uses) though.
-John
Anthony Minessale wrote:
We have a concept called the "directory interface" not to be confused with the "user directory". The directory interface is a pluggable abstract API that looks and feels like LDAP only you can plug in anything you want to implement the functions.
mod_ldap is a module that registers to this interface and connects LDAP to it. So essentially you load mod_ldap then you use the freeswitch directory interface as you would have used the ldap code and it will carry over.
There is a mod_dialplan_directory who uses the directory interface to ask for a dialplan, and installs the results into an extension. In the case of mod_ldap obviously it allows you to get your dialplan from LDAP.
Now also in mod_ldap, there is some code someone recently contributed to tie our XML interface to LDAP, This is more interesting because then when anything in FreeSWITCH tries to lookup a user, dialplan entry or anything else in our XML config, all the important details are passed to LDAP where it can make a query, pull the info out of LDAP and deliver it back to FreeSWITCH as the XML it was looking for. This allows you to make all of the registrations, dialplan etc real time driven by LDAP, you can also bind a perl or lua script to this operation as well as mod_xml_curl who will turn the request into an HTTP post to a web server to fetch the data.
On Wed, May 28, 2008 at 8:09 AM, Michael Jerris <mike@jerris.com <mailto:mike@jerris.com>> wrote:
Currently the directory interface is only used for that dialplan, I would like to enhance that in the future. The directory dialploan uses a filter of exten=destination number, and then has name/value pairs, I will see if I can find the schema we used back when we developed it, short of that, the code is the best reference on that. Another option is to use mod_xml_curl and have your cgi back end to ldap of your choice. This will give you more flexibility to use other caller information in your ldap lookup.
Mike
On May 28, 2008, at 1:58 AM, Faraz R. Khan wrote:
> First of all- Amazing project. Tired of asterisk deadlocking all the > time we have been deploying asterisk with OpenSER as the registrar. > Freeswitch is a huge relief! > > This is an extremely important feature we have been looking for. > Asterisk realtime ldap integration is very flaky. I found this page: > > http://wiki.freeswitch.org/wiki/FreeSwitch_Dialplan_Directory > > But there are no clues as to the schema, the queries generated and > what > exactly it can hold in Ldap. I am also curious to know whether sofia's > sip registrations, gateways etc can be kept in LDAP. > > We are basically developing an extensive plugin based control panel > and > a Asterisk module is already ready. However, we are writing > asterisk .conf files for managing asterisk. We would be quite > pleased to > develop a FreeSwitch Ldap plugin to manage users,sip gateways, groups, > features, etc. > > Though the XML configuration file is extremely easy to parse and > write, > pure LDAP integration would be amazing. Any pointers on this would be > appreciated. > > > -- > Faraz R Khan > Chief Architect > Emergen Consulting Pvt Ltd > +92.21.529.0381 x200 > www.emergen.biz <http://www.emergen.biz> > > > _______________________________________________ > Freeswitch-users mailing list > Freeswitch-users@lists.freeswitch.org <mailto:Freeswitch-users@lists.freeswitch.org> > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users > http://www.freeswitch.org
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org <mailto:Freeswitch-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/
AIM: anthm MSN:anthony_minessale@hotmail.com <mailto:MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com <mailto:PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <mailto:sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 <http://iax:guest@conference.freeswitch.org/888> googletalk:conf+888@conference.freeswitch.org <mailto:googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
------------------------------------------------------------------------
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org plain text document attachment (sample.ldif) dn: cn=1000,ou=192.168.0.102,o=galacticbell,dc=galacticbell,dc=com objectClass: top objectClass: sipCred objectClass: inetOrgPerson cn: 1000 sn: 1000 idname: 1000 param: password param: vm-password paramvalue: 1234 paramvalue: 0000 variable: accountcode variablevalue: 1000
plain text document attachment (garbageschema.schema) attributetype ( 1.3.6.1.4.1.65535.1 NAME 'Reserved' DESC 'Reserved attribute' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetype ( 1.3.6.1.4.1.65535.2.1.1 NAME 'FSname' DESC 'exten FSname import from exten name= in xml' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetype ( 1.3.6.1.4.1.65535.2.1.2 NAME 'exten' DESC 'exten number' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.65535.2.1.3 NAME 'application' DESC 'action for exten' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.65535.2.1.4 NAME 'data' DESC 'argument to application' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.65535.2.1.53 NAME 'field' DESC 'target for regular expression' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.65535.2.1.6 NAME 'expression' DESC 'regular expression to matich in field' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.65535.2.1.7 NAME 'regex' DESC 'BOOL if true process regex' SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 )
attributetype ( 1.3.6.1.4.1.65535.3.1.1 NAME 'context' DESC 'context of exten' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
objectclass ( 1.3.6.1.4.1.65535.3.2.1 NAME 'contextObject' SUP top AUXILIARY DESC 'Context' MUST ( context ) )
objectclass ( 1.3.6.1.4.1.65535.2.2.2 NAME 'extenObject' SUP top AUXILIARY DESC 'exten object' MUST ( FSname $ exten $ application $ data ) MAY ( regex $ expression $ field ) )
attributetype ( 1.3.6.1.4.1.65535.4.1.1 NAME 'FShost' DESC 'BOOL if true process regex' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.65535.4.1.2 NAME 'section' DESC 'BOOL if true process regex' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.65535.4.1.3 NAME 'tag' DESC 'BOOL if true process regex' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.65535.4.1.4 NAME 'idname' DESC 'BOOL if true process regex' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.65535.4.1.5 NAME 'param' DESC 'BOOL if true process regex' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.65535.4.1.6 NAME 'paramvalue' DESC 'BOOL if true process regex' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.65535.4.1.7 NAME 'variable' DESC 'BOOL if true process regex' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.65535.4.1.8 NAME 'variablevalue' EQUALITY caseIgnoreIA5Match DESC 'BOOL if true process regex' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
objectclass ( 1.3.6.1.4.1.65535.4.2.1 NAME 'sipCred' SUP top AUXILIARY DESC 'sip object' MUST ( idname $ param $ paramvalue ) MAY ( variable $ variablevalue ) )
objectclass ( 1.3.6.1.4.1.65535.4.2.2 NAME 'fsDirectory' SUP top AUXILIARY DESC 'fs object' MUST ( idname ) MAY ( tag $ section $ FShost ) )
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
For sip auth we do pass all the hash information from the auth headers when it does the lookup, so you are able to do the auth in your module if you care to. We are unable to pass up the raw password as we never actually have that information. Mike On Jun 1, 2008, at 4:11 PM, John Skopis (Lists) wrote:
Hi, I had some free time and decided to add sasl support to mod_xml_ldap. I only tested kerberos5 auth though.
I also added support for search filters.
The problem with the xml_ldap directory stuff is that since freeswitch never actually sends the hash (or cleartext password) to the module it can't bind as the extension to compare.
I would have much rather registered a module as an authentication provider vs a xml provider. As I understand this portion of code is somewhere in between the core and mod_sofia so it would need to be done as an extension to mod_sofia.
All it does is connect to ldap as a privileged user, search for a freeswitch extension, generate xml, and send the xml to fs.
If I find some more free time I may add support for requested attrs in the ldap query. If you take a look at the code it currently grabs all attrs and then joins on key=keyval. I did this so ldap schema didn't have to be extended everytime the fs xml schema is extended. The reason would be rather than requesting 100 attrs and iterating through them all just request the ~4 required to generate the xml and iterate through them.
Also startls/ssl support might be nice ;]
-john
PS Until someone adds the config to tree (I cant write the config file =\) here it is: http://rafb.net/p/A37tLo10.html
Faraz R. Khan wrote:
Thanks a lot. I intend to use it mostly as a SIP user directory. For the dial-plan I dont mind parsing and syncing XML file across servers (if there were a small cluster). The main deal is AUTHENTICATION. The authentication scheme I wish to keep is Kerberos (with SASL in Ldap for binding). This way all my credentials are centralized, be it SIP or mail.
This would be a great achievement for me and many enterprises having thousands of identities. The dialplan stays fairly static once developed so I dont mind that being in a XML file. The dynamic stuff (user credentials) I wish to keep in a centralized store such as LDAP.
On Wed, 2008-05-28 at 20:12 -0500, John Skopis (Lists) wrote:
At one point I was very interested in this...then I got a job. =[
I thought mod_ldap was more of a PoC than anything. It might work (I couldn't get it working and unfortunately don't remember exactly why..) but there really isn't much point. I would have to do at least 5 ldap queries (if not more) to get the most of the same functionality as the XML dialplan. Also, the elegance of stackable functionality in the XML dialplan is hard to imitate, at least with the any amount of efficiency. If you don't need to stack actions a regular expression will almost certainly be better.
Attached is the schema, config, and sample ldif I used to get the xml stuff working.
With a little effort it could work with an existing schema (possibly the ITU recomended LDAP schema that ser uses). I am not sure how easy it would be to get the same flexibility as key/value pairs (like the FS xml uses) though.
-John
Anthony Minessale wrote:
We have a concept called the "directory interface" not to be confused with the "user directory". The directory interface is a pluggable abstract API that looks and feels like LDAP only you can plug in anything you want to implement the functions.
mod_ldap is a module that registers to this interface and connects LDAP to it. So essentially you load mod_ldap then you use the freeswitch directory interface as you would have used the ldap code and it will carry over.
There is a mod_dialplan_directory who uses the directory interface to ask for a dialplan, and installs the results into an extension. In the case of mod_ldap obviously it allows you to get your dialplan from LDAP.
Now also in mod_ldap, there is some code someone recently contributed to tie our XML interface to LDAP, This is more interesting because then when anything in FreeSWITCH tries to lookup a user, dialplan entry or anything else in our XML config, all the important details are passed to LDAP where it can make a query, pull the info out of LDAP and deliver it back to FreeSWITCH as the XML it was looking for. This allows you to make all of the registrations, dialplan etc real time driven by LDAP, you can also bind a perl or lua script to this operation as well as mod_xml_curl who will turn the request into an HTTP post to a web server to fetch the data.
On Wed, May 28, 2008 at 8:09 AM, Michael Jerris <mike@jerris.com <mailto:mike@jerris.com>> wrote:
Currently the directory interface is only used for that dialplan, I would like to enhance that in the future. The directory dialploan uses a filter of exten=destination number, and then has name/ value pairs, I will see if I can find the schema we used back when we developed it, short of that, the code is the best reference on that. Another option is to use mod_xml_curl and have your cgi back end to ldap of your choice. This will give you more flexibility to use other caller information in your ldap lookup.
Mike
On May 28, 2008, at 1:58 AM, Faraz R. Khan wrote:
First of all- Amazing project. Tired of asterisk deadlocking all the time we have been deploying asterisk with OpenSER as the registrar. Freeswitch is a huge relief!
This is an extremely important feature we have been looking for. Asterisk realtime ldap integration is very flaky. I found this page:
http://wiki.freeswitch.org/wiki/FreeSwitch_Dialplan_Directory
But there are no clues as to the schema, the queries generated and what exactly it can hold in Ldap. I am also curious to know whether sofia's sip registrations, gateways etc can be kept in LDAP.
We are basically developing an extensive plugin based control panel and a Asterisk module is already ready. However, we are writing asterisk .conf files for managing asterisk. We would be quite pleased to develop a FreeSwitch Ldap plugin to manage users,sip gateways, groups, features, etc.
Though the XML configuration file is extremely easy to parse and write, pure LDAP integration would be amazing. Any pointers on this would be appreciated.
-- Faraz R Khan Chief Architect Emergen Consulting Pvt Ltd +92.21.529.0381 x200 www.emergen.biz <http://www.emergen.biz>
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org <mailto:Freeswitch-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org <mailto:Freeswitch-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/
AIM: anthm MSN:anthony_minessale@hotmail.com <mailto:MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com <mailto:PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <mailto:sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 <http://iax:guest@conference.freeswitch.org/888> googletalk:conf+888@conference.freeswitch.org <mailto:googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
------------------------------------------------------------------------
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org plain text document attachment (sample.ldif) dn: cn=1000,ou=192.168.0.102,o=galacticbell,dc=galacticbell,dc=com objectClass: top objectClass: sipCred objectClass: inetOrgPerson cn: 1000 sn: 1000 idname: 1000 param: password param: vm-password paramvalue: 1234 paramvalue: 0000 variable: accountcode variablevalue: 1000
plain text document attachment (garbageschema.schema) attributetype ( 1.3.6.1.4.1.65535.1 NAME 'Reserved' DESC 'Reserved attribute' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetype ( 1.3.6.1.4.1.65535.2.1.1 NAME 'FSname' DESC 'exten FSname import from exten name= in xml' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetype ( 1.3.6.1.4.1.65535.2.1.2 NAME 'exten' DESC 'exten number' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.65535.2.1.3 NAME 'application' DESC 'action for exten' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.65535.2.1.4 NAME 'data' DESC 'argument to application' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.65535.2.1.53 NAME 'field' DESC 'target for regular expression' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.65535.2.1.6 NAME 'expression' DESC 'regular expression to matich in field' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.65535.2.1.7 NAME 'regex' DESC 'BOOL if true process regex' SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 )
attributetype ( 1.3.6.1.4.1.65535.3.1.1 NAME 'context' DESC 'context of exten' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
objectclass ( 1.3.6.1.4.1.65535.3.2.1 NAME 'contextObject' SUP top AUXILIARY DESC 'Context' MUST ( context ) )
objectclass ( 1.3.6.1.4.1.65535.2.2.2 NAME 'extenObject' SUP top AUXILIARY DESC 'exten object' MUST ( FSname $ exten $ application $ data ) MAY ( regex $ expression $ field ) )
attributetype ( 1.3.6.1.4.1.65535.4.1.1 NAME 'FShost' DESC 'BOOL if true process regex' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.65535.4.1.2 NAME 'section' DESC 'BOOL if true process regex' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.65535.4.1.3 NAME 'tag' DESC 'BOOL if true process regex' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.65535.4.1.4 NAME 'idname' DESC 'BOOL if true process regex' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.65535.4.1.5 NAME 'param' DESC 'BOOL if true process regex' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.65535.4.1.6 NAME 'paramvalue' DESC 'BOOL if true process regex' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.65535.4.1.7 NAME 'variable' DESC 'BOOL if true process regex' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.65535.4.1.8 NAME 'variablevalue' EQUALITY caseIgnoreIA5Match DESC 'BOOL if true process regex' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
objectclass ( 1.3.6.1.4.1.65535.4.2.1 NAME 'sipCred' SUP top AUXILIARY DESC 'sip object' MUST ( idname $ param $ paramvalue ) MAY ( variable $ variablevalue ) )
objectclass ( 1.3.6.1.4.1.65535.4.2.2 NAME 'fsDirectory' SUP top AUXILIARY DESC 'fs object' MUST ( idname ) MAY ( tag $ section $ FShost ) )
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Michael Jerris wrote:
For sip auth we do pass all the hash information from the auth headers when it does the lookup, so you are able to do the auth in your module if you care to. We are unable to pass up the raw password as we never actually have that information.
Mike
I remember now... sip phones != mail clients. but if they were... Thanks for reminding me Mike. I am not exactly sure how difficult it is to do digest auth in openldap or AD. If I manage to find some time I will look into it though, -john
Sounds amazing. Thanks a ton! John Skopis (Lists) wrote:
Hi, I had some free time and decided to add sasl support to mod_xml_ldap. I only tested kerberos5 auth though.
I also added support for search filters.
The problem with the xml_ldap directory stuff is that since freeswitch never actually sends the hash (or cleartext password) to the module it can't bind as the extension to compare.
I would have much rather registered a module as an authentication provider vs a xml provider. As I understand this portion of code is somewhere in between the core and mod_sofia so it would need to be done as an extension to mod_sofia.
All it does is connect to ldap as a privileged user, search for a freeswitch extension, generate xml, and send the xml to fs.
If I find some more free time I may add support for requested attrs in the ldap query. If you take a look at the code it currently grabs all attrs and then joins on key=keyval. I did this so ldap schema didn't have to be extended everytime the fs xml schema is extended. The reason would be rather than requesting 100 attrs and iterating through them all just request the ~4 required to generate the xml and iterate through them.
Also startls/ssl support might be nice ;]
-john
PS Until someone adds the config to tree (I cant write the config file =\) here it is: http://rafb.net/p/A37tLo10.html
Faraz R. Khan wrote:
Thanks a lot. I intend to use it mostly as a SIP user directory. For the dial-plan I dont mind parsing and syncing XML file across servers (if there were a small cluster). The main deal is AUTHENTICATION. The authentication scheme I wish to keep is Kerberos (with SASL in Ldap for binding). This way all my credentials are centralized, be it SIP or mail.
This would be a great achievement for me and many enterprises having thousands of identities. The dialplan stays fairly static once developed so I dont mind that being in a XML file. The dynamic stuff (user credentials) I wish to keep in a centralized store such as LDAP.
On Wed, 2008-05-28 at 20:12 -0500, John Skopis (Lists) wrote:
At one point I was very interested in this...then I got a job. =[
I thought mod_ldap was more of a PoC than anything. It might work (I couldn't get it working and unfortunately don't remember exactly why..) but there really isn't much point. I would have to do at least 5 ldap queries (if not more) to get the most of the same functionality as the XML dialplan. Also, the elegance of stackable functionality in the XML dialplan is hard to imitate, at least with the any amount of efficiency. If you don't need to stack actions a regular expression will almost certainly be better.
Attached is the schema, config, and sample ldif I used to get the xml stuff working.
With a little effort it could work with an existing schema (possibly the ITU recomended LDAP schema that ser uses). I am not sure how easy it would be to get the same flexibility as key/value pairs (like the FS xml uses) though.
-John
Anthony Minessale wrote:
We have a concept called the "directory interface" not to be confused with the "user directory". The directory interface is a pluggable abstract API that looks and feels like LDAP only you can plug in anything you want to implement the functions.
mod_ldap is a module that registers to this interface and connects LDAP to it. So essentially you load mod_ldap then you use the freeswitch directory interface as you would have used the ldap code and it will carry over.
There is a mod_dialplan_directory who uses the directory interface to ask for a dialplan, and installs the results into an extension. In the case of mod_ldap obviously it allows you to get your dialplan from LDAP.
Now also in mod_ldap, there is some code someone recently contributed to tie our XML interface to LDAP, This is more interesting because then when anything in FreeSWITCH tries to lookup a user, dialplan entry or anything else in our XML config, all the important details are passed to LDAP where it can make a query, pull the info out of LDAP and deliver it back to FreeSWITCH as the XML it was looking for. This allows you to make all of the registrations, dialplan etc real time driven by LDAP, you can also bind a perl or lua script to this operation as well as mod_xml_curl who will turn the request into an HTTP post to a web server to fetch the data.
On Wed, May 28, 2008 at 8:09 AM, Michael Jerris <mike@jerris.com <mailto:mike@jerris.com>> wrote:
Currently the directory interface is only used for that dialplan, I would like to enhance that in the future. The directory dialploan uses a filter of exten=destination number, and then has name/value pairs, I will see if I can find the schema we used back when we developed it, short of that, the code is the best reference on that. Another option is to use mod_xml_curl and have your cgi back end to ldap of your choice. This will give you more flexibility to use other caller information in your ldap lookup.
Mike
On May 28, 2008, at 1:58 AM, Faraz R. Khan wrote:
> First of all- Amazing project. Tired of asterisk deadlocking all the > time we have been deploying asterisk with OpenSER as the registrar. > Freeswitch is a huge relief! > > This is an extremely important feature we have been looking for. > Asterisk realtime ldap integration is very flaky. I found this page: > > http://wiki.freeswitch.org/wiki/FreeSwitch_Dialplan_Directory > > But there are no clues as to the schema, the queries generated and > what > exactly it can hold in Ldap. I am also curious to know whether sofia's > sip registrations, gateways etc can be kept in LDAP. > > We are basically developing an extensive plugin based control panel > and > a Asterisk module is already ready. However, we are writing > asterisk .conf files for managing asterisk. We would be quite > pleased to > develop a FreeSwitch Ldap plugin to manage users,sip gateways, groups, > features, etc. > > Though the XML configuration file is extremely easy to parse and > write, > pure LDAP integration would be amazing. Any pointers on this would be > appreciated. > > > -- > Faraz R Khan > Chief Architect > Emergen Consulting Pvt Ltd > +92.21.529.0381 x200 > www.emergen.biz <http://www.emergen.biz> > > > _______________________________________________ > Freeswitch-users mailing list > Freeswitch-users@lists.freeswitch.org <mailto:Freeswitch-users@lists.freeswitch.org> > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users > http://www.freeswitch.org
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org <mailto:Freeswitch-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/
AIM: anthm MSN:anthony_minessale@hotmail.com <mailto:MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com <mailto:PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <mailto:sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 <http://iax:guest@conference.freeswitch.org/888> googletalk:conf+888@conference.freeswitch.org <mailto:googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
------------------------------------------------------------------------
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org plain text document attachment (sample.ldif) dn: cn=1000,ou=192.168.0.102,o=galacticbell,dc=galacticbell,dc=com objectClass: top objectClass: sipCred objectClass: inetOrgPerson cn: 1000 sn: 1000 idname: 1000 param: password param: vm-password paramvalue: 1234 paramvalue: 0000 variable: accountcode variablevalue: 1000
plain text document attachment (garbageschema.schema) attributetype ( 1.3.6.1.4.1.65535.1 NAME 'Reserved' DESC 'Reserved attribute' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetype ( 1.3.6.1.4.1.65535.2.1.1 NAME 'FSname' DESC 'exten FSname import from exten name= in xml' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetype ( 1.3.6.1.4.1.65535.2.1.2 NAME 'exten' DESC 'exten number' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.65535.2.1.3 NAME 'application' DESC 'action for exten' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.65535.2.1.4 NAME 'data' DESC 'argument to application' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.65535.2.1.53 NAME 'field' DESC 'target for regular expression' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.65535.2.1.6 NAME 'expression' DESC 'regular expression to matich in field' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.65535.2.1.7 NAME 'regex' DESC 'BOOL if true process regex' SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 )
attributetype ( 1.3.6.1.4.1.65535.3.1.1 NAME 'context' DESC 'context of exten' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
objectclass ( 1.3.6.1.4.1.65535.3.2.1 NAME 'contextObject' SUP top AUXILIARY DESC 'Context' MUST ( context ) )
objectclass ( 1.3.6.1.4.1.65535.2.2.2 NAME 'extenObject' SUP top AUXILIARY DESC 'exten object' MUST ( FSname $ exten $ application $ data ) MAY ( regex $ expression $ field ) )
attributetype ( 1.3.6.1.4.1.65535.4.1.1 NAME 'FShost' DESC 'BOOL if true process regex' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.65535.4.1.2 NAME 'section' DESC 'BOOL if true process regex' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.65535.4.1.3 NAME 'tag' DESC 'BOOL if true process regex' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.65535.4.1.4 NAME 'idname' DESC 'BOOL if true process regex' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.65535.4.1.5 NAME 'param' DESC 'BOOL if true process regex' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.65535.4.1.6 NAME 'paramvalue' DESC 'BOOL if true process regex' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.65535.4.1.7 NAME 'variable' DESC 'BOOL if true process regex' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.65535.4.1.8 NAME 'variablevalue' EQUALITY caseIgnoreIA5Match DESC 'BOOL if true process regex' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
objectclass ( 1.3.6.1.4.1.65535.4.2.1 NAME 'sipCred' SUP top AUXILIARY DESC 'sip object' MUST ( idname $ param $ paramvalue ) MAY ( variable $ variablevalue ) )
objectclass ( 1.3.6.1.4.1.65535.4.2.2 NAME 'fsDirectory' SUP top AUXILIARY DESC 'fs object' MUST ( idname ) MAY ( tag $ section $ FShost ) )
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Faraz R Khan Chief Architect Emergen Consulting Pvt Ltd +92.21.529.0381 x200 www.emergen.biz
participants (4)
-
Anthony Minessale
-
Faraz R. Khan
-
John Skopis (Lists)
-
Michael Jerris